The JVMTM Tool Interface (JVM TI)
is a programming interface used by development and monitoring tools.
It provides both a way to inspect the state and
to control the execution of applications running in the
JavaTM virtual machine (VM).
JVM TI is intended to provide a VM interface for the full breadth of tools
that need access to VM state, including but not limited to: profiling,
debugging, monitoring, thread analysis, and coverage analysis tools.
JVM TI may not be available in all implementations of the JavaTM virtual
machine.
JVM TI is a two-way interface.
A client of JVM TI, hereafter called an agent,
can be notified of
interesting occurrences through events.
JVM TI
can query and control the application through many
functions,
either in response to events or
independent of them.
Agents run in the same process with and communicate directly with
the virtual machine executing
the application being examined. This communication is
through a native interface (JVM TI). The native in-process interface allows
maximal control with minimal intrusion on the part of a tool.
Typically, agents are relatively compact. They can be controlled
by a separate process which implements the bulk of a tool's
function without interfering with the target application's normal execution.
Architecture
Tools can be written directly to JVM TI or indirectly
through higher level interfaces.
The Java Platform Debugger Architecture includes JVM TI, but also
contains higher-level, out-of-process debugger interfaces. The higher-level
interfaces are more appropriate than JVM TI for many tools.
For more information on the Java Platform Debugger Architecture,
see the
.
Writing Agents
Agents can be written in any native language that supports C
language calling conventions and C or C++
definitions.
The function, event, data type, and constant definitions needed for
using JVM TI are defined in the include file jvmti.h.
To use these definitions add the J2SETM include directory
to your include path and add
#include <jvmti.h>
to your source code.
Deploying Agents
An agent is deployed in a platform specific manner but is typically the
platform equivalent of a dynamic library. On the WindowsTM operating
system, for example, an agent library is a "Dynamic Linked Library" (DLL).
On the SolarisTM Operating Environment, an agent library is a shared
object (.so file).
An agent may be started at VM startup by specifying the agent library
name using a command line option.
Some implementations may support a mechanism to
start agents in the live phase.
The details of how this is initiated are implementation specific.
Agent Command Line Options
The term "command-line option" is used below to
mean options supplied in the JavaVMInitArgs argument
to the JNI_CreateJavaVM function of the JNI
Invocation API.
One of the two following
command-line options is used on VM startup to
properly load and run agents.
These arguments identify the library containing
the agent as well as an options
string to be passed in at startup.
-agentlib:<agent-lib-name>=<options>
The name following -agentlib: is the name of the
library to load. Lookup of the library, both its full name and location,
proceeds in a platform-specific manner.
Typically, the <agent-lib-name> is expanded to an
operating system specific file name.
The <options> will be passed to the agent on start-up.
For example, if the option
-agentlib:foo=opt1,opt2 is specified, the VM will attempt to
load the shared library foo.dll from the system PATH
under WindowsTM or libfoo.so from the
LD_LIBRARY_PATH under the SolarisTM operating environment.
-agentpath:<path-to-agent>=<options>
The path following -agentpath: is the absolute path from which
to load the library.
No library name expansion will occur.
The <options> will be passed to the agent on start-up.
For example, if the option
-agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to
load the shared library c:\myLibs\foo.dll.
The start-up routine Agent_OnLoad
in the library will be invoked.
Libraries loaded with -agentlib: or -agentpath:
will be searched for JNI native method implementations to facilitate the
use of Java programming language code in tools, as is needed for
bytecode instrumentation.
The agent libraries will be searched after all other libraries have been
searched (agents wishing to override or intercept the native method
implementations of non-agent methods can use the
NativeMethodBind event).
These switches do the above and nothing more - they do not change the
state of the VM or JVM TI. No command line options are needed
to enable JVM TI
or aspects of JVM TI, this is handled programmatically
by the use of
capabilities.
Agent Start-Up
The VM starts each agent by invoking a start-up function.
If the agent is started in the OnLoadphase the function
Agent_OnLoad
will be invoked.
If the agent is started in the live
phase the function
Agent_OnAttach
will be invoked.
Exactly one call to a start-up function is made per agent.
Agent Start-Up (OnLoad phase)
If an agent is started during the OnLoad phase then its
agent library must export a start-up function with the following prototype:
The VM will start the agent by calling this function.
It will be called early enough in VM initialization that:
system properties
may be set before they have been used in the start-up of the VM
the full set of
capabilities
is still available (note that capabilities that configure the VM
may only be available at this time--see the
Capability function section)
no bytecodes have executed
no classes have been loaded
no objects have been created
The VM will call the Agent_OnLoad function with
<options> as the second argument -
that is, using the command-line option examples,
"opt1,opt2" will be passed to the char *options
argument of Agent_OnLoad.
The options argument is encoded as a
modified UTF-8 string.
If =<options> is not specified,
a zero length string is passed to options.
The lifespan of the options string is the Agent_OnLoad
call. If needed beyond this time the string or parts of the string must
be copied.
The period between when Agent_OnLoad is called and when it
returns is called the OnLoad phase.
Since the VM is not initialized during the OnLoad
phase,
the set of allowed operations
inside Agent_OnLoad is restricted (see the function descriptions for the
functionality available at this time).
The agent can safely process the options and set
event callbacks with SetEventCallbacks. Once
the VM initialization event is received
(that is, the VMInit
callback is invoked), the agent
can complete its initialization.
Rationale:
Early startup is required so that agents can set the desired capabilities,
many of which must be set before the VM is initialized.
In JVMDI, the -Xdebug command-line option provided
very coarse-grain control of capabilities.
JVMPI implementations use various tricks to provide a single "JVMPI on" switch.
No reasonable command-line
option could provide the fine-grain of control required to balance needed capabilities vs
performance impact.
Early startup is also needed so that agents can control the execution
environment - modifying the file system and system properties to install
their functionality.
The return value from Agent_OnLoad is used to indicate an error.
Any value other than zero indicates an error and causes termination of the VM.
Agent Start-Up (Live phase)
A VM may support a mechanism that allows agents to be started in the VM during the live
phase. The details of how this is supported,
are implementation specific. For example, a tool may use some platform specific mechanism,
or implementation specific API, to attach to the running VM, and request it start a given
agent.
If an agent is started during the live phase then its agent library
must export a start-up function
with the following prototype:
The VM will start the agent by calling this function.
It will be called in the context of a thread
that is attached to the VM. The first argument <vm> is the Java VM.
The <options> argument is the startup options provided to the agent.
<options> is encoded as a modified UTF-8
string.
If startup options were not provided, a zero length string is passed to
options. The lifespan of the options string is the
Agent_OnAttach call. If needed beyond this time the string or parts of
the string must be copied.
Note that some capabilities
may not be available in the live phase.
The Agent_OnAttach function initializes the agent and returns a value
to the VM to indicate if an error occurred. Any value other than zero indicates an error.
An error does not cause the VM to terminate. Instead the VM ignores the error, or takes
some implementation specific action -- for example it might print an error to standard error,
or record the error in a system log.
Agent Shutdown
The library may optionally export a
shutdown function with the following prototype:
JNIEXPORT void JNICALL
Agent_OnUnload(JavaVM *vm)
This function will be called by the VM when the library is about to be unloaded.
The library will be unloaded and this function will be called if some platform specific
mechanism causes the unload (an unload mechanism is not specified in this document)
or the library is (in effect) unloaded by the termination of the VM whether through
normal termination or VM failure, including start-up failure.
Uncontrolled shutdown is, of couse, an exception to this rule.
Note the distinction between this function and the
VM Death event: for the VM Death event
to be sent, the VM must have run at least to the point of initialization and a valid
JVM TI environment must exist which has set a callback for VMDeath
and enabled the event
None of these are required for Agent_OnUnload and this function
is also called if the library is unloaded for other reasons.
In the case that a VM Death event is sent, it will be sent before this
function is called (assuming this function is called due to VM termination).
This function can be used to clean-up resources allocated by the agent.
JAVA_TOOL_OPTIONS
Since the command-line cannot always be accessed or modified, for example in embedded VMs
or simply VMs launched deep within scripts, a JAVA_TOOL_OPTIONS variable is
provided so that agents may be launched in these cases.
Platforms which support environment variables or other named strings, may support the
JAVA_TOOL_OPTIONS variable. This variable will be broken into options at white-space
boundaries. White-space characters include space, tab, carriage-return, new-line,
vertical-tab, and form-feed. Sequences of white-space characters are considered
equivalent to a single white-space character. No white-space is included in the options
unless quoted. Quoting is as follows:
All characters enclosed between a pair of single quote marks (''), except a single
quote, are quoted.
Double quote characters have no special meaning inside a pair of single quote marks.
All characters enclosed between a pair of double quote marks (""), except a double
quote, are quoted.
Single quote characters have no special meaning inside a pair of double quote marks.
A quoted part can start or end anywhere in the variable.
White-space characters have no special meaning when quoted -- they are included in
the option like any other character and do not mark white-space boundaries.
The pair of quote marks is not included in the option.
JNI_CreateJavaVM (in the JNI Invocation API) will prepend these options to the options supplied
in its JavaVMInitArgs argument. Platforms may disable this feature in cases where security is
a concern; for example, the Reference Implementation disables this feature on Unix systems when
the effective user or group ID differs from the real ID.
This feature is intended to support the initialization of tools -- specifically including the
launching of native or Java programming language agents. Multiple tools may wish to use this
feature, so the variable should not be overwritten, instead, options should be appended to
the variable. Note that since the variable is processed at the time of the JNI Invocation
API create VM call, options processed by a launcher (e.g., VM selection options) will not be handled.
Environments
The JVM TI specification supports the use of multiple simultaneous
JVM TI agents.
Each agent has its own JVM TI environment.
That is, the JVM TI state is
separate for each agent - changes to one environment do not affect the
others. The state of a JVM TI
environment includes:
Although their JVM TI state
is separate, agents inspect and modify the shared state
of the VM, they also share the native environment in which they execute.
As such, an agent can perturb the results of other agents or cause them
to fail. It is the responsibility of the agent writer to specify the level
of compatibility with other agents. JVM TI implementations are not capable
of preventing destructive interactions between agents. Techniques to reduce
the likelihood of these occurrences are beyond the scope of this document.
An agent creates a JVM TI environment
by passing a JVM TI version
as the interface ID to the JNI Invocation API function
.
See Accessing JVM TI Functions
for more details on the creation and use of
JVM TI environments.
Typically, JVM TI environments are created by calling GetEnv from
Agent_OnLoad.
Bytecode Instrumentation
This interface does not include some events that one might expect in an interface with
profiling support. Some examples include object allocation events and full speed
method enter and exit events. The interface instead provides support for
bytecode instrumentation, the ability to alter the Java virtual machine
bytecode instructions which comprise the target program. Typically, these alterations
are to add "events" to the code of a method - for example, to add, at the beginning of a method,
a call to MyProfiler.methodEntered().
Since the changes are purely additive, they do not modify application
state or behavior.
Because the inserted agent code is standard bytecodes, the VM can run at full speed,
optimizing not only the target program but also the instrumentation. If the
instrumentation does not involve switching from bytecode execution, no expensive
state transitions are needed. The result is high performance events.
This approach also provides complete control to the agent: instrumentation can be
restricted to "interesting" portions of the code (e.g., the end user's code) and
can be conditional. Instrumentation can run entirely in Java programming language
code or can call into the native agent. Instrumentation can simply maintain
counters or can statistically sample events.
Instrumentation can be inserted in one of three ways:
Static Instrumentation: The class file is instrumented before it
is loaded into the VM - for example, by creating a duplicate directory of
*.class files which have been modified to add the instrumentation.
This method is extremely awkward and, in general, an agent cannot know
the origin of the class files which will be loaded.
Load-Time Instrumentation: When a class file is loaded by the VM, the raw
bytes of the class file are sent for instrumentation to the agent.
The ClassFileLoadHook
event, triggered by the class load,
provides this functionality. This mechanism provides efficient
and complete access to one-time instrumentation.
Dynamic Instrumentation: A class which is already loaded (and possibly
even running) is modified. This optional feature is provided by the
ClassFileLoadHook event, triggered by calling the
RetransformClasses function.
Classes can be modified multiple times and can be returned to their
original state.
The mechanism allows instrumentation which changes during the
course of execution.
The class modification functionality provided in this interface
is intended to provide a mechanism for instrumentation
(the ClassFileLoadHook event
and the RetransformClasses function)
and, during development, for fix-and-continue debugging
(the RedefineClasses function).
Care must be taken to avoid perturbing dependencies, especially when
instrumenting core classes. For example, an approach to getting notification
of every object allocation is to instrument the constructor on
Object. Assuming that the constructor is initially
empty, the constructor could be changed to:
public Object() {
MyProfiler.allocationTracker(this);
}
However, if this change was made using the
ClassFileLoadHook
event then this might impact a typical VM as follows:
the first created object will call the constructor causing a class load of
MyProfiler; which will then cause
object creation, and since MyProfiler isn't loaded yet,
infinite recursion; resulting in a stack overflow. A refinement of this
would be to delay invoking the tracking method until a safe time. For
example, trackAllocations could be set in the
handler for the VMInit event.
static boolean trackAllocations = false;
public Object() {
if (trackAllocations) {
MyProfiler.allocationTracker(this);
}
}
The SetNativeMethodPrefix allows native methods
to be instrumented by the use of wrapper methods.
Modified UTF-8 String Encoding
JVM TI uses modified UTF-8 to encode character strings.
This is the same encoding used by JNI.
Modified UTF-8 differs
from standard UTF-8 in the representation of supplementary characters
and of the null character. See the
section of the JNI specification for details.
Specification Context
Since this interface provides access to the state of applications running in the
Java virtual machine;
terminology refers to the Java platform and not the native
platform (unless stated otherwise). For example:
"thread" means Java programming language thread.
"stack frame" means Java virtual machine stack frame.
"class" means Java programming language class.
"heap" means Java virtual machine heap.
"monitor" means Java programming language object monitor.
Sun, Sun Microsystems, the Sun logo, Java, and JVM
are trademarks or registered trademarks of Sun
Microsystems, Inc. in the U.S. and other countries.
Functions
Accessing Functions
Native code accesses JVM TI features
by calling JVM TI functions.
Access to JVM TI functions is by use of an interface pointer
in the same manner as
are accessed.
The JVM TI interface pointer is called the
environment pointer.
An environment pointer is a pointer to an environment and has
the type jvmtiEnv*.
An environment has information about its JVM TI connection.
The first value in the environment is a pointer to the function table.
The function table is an array of pointers to JVM TI functions.
Every function pointer is at a predefined offset inside the
array.
When used from the C language:
double indirection is used to access the functions;
the environment pointer provides context and is the first
parameter of each function call; for example:
When used from the C++ language:
functions are accessed as member functions of jvmtiEnv;
the environment pointer is not passed to the function call; for example:
Unless otherwise stated, all examples and declarations in this
specification use the C language.
A JVM TI environment can be obtained through the JNI Invocation API
GetEnv function:
Each call to GetEnv
creates a new JVM TI connection and thus
a new JVM TI environment.
The version argument of GetEnv must be
a JVM TI version.
The returned environment may have a different version than the
requested version but the returned environment must be compatible.
GetEnv will return JNI_EVERSION if a
compatible version is not available, if JVM TI is not supported or
JVM TI is not supported in the current VM configuration.
Other interfaces may be added for creating JVM TI environments
in specific contexts.
Each environment has its own state (for example,
desired events,
event handling functions, and
capabilities).
An environment is released with
DisposeEnvironment.
Thus, unlike JNI which has one environment per thread, JVM TI environments work
across threads and are created dynamically.
Function Return Values
JVM TI functions always return an
error code via the
jvmtiError function return value.
Some functions can return additional
values through pointers provided by the calling function.
In some cases, JVM TI functions allocate memory that your program must
explicitly deallocate. This is indicated in the individual JVM TI
function descriptions. Empty lists, arrays, sequences, etc are
returned as NULL.
In the event that the JVM TI function encounters
an error (any return value other than JVMTI_ERROR_NONE) the values
of memory referenced by argument pointers is undefined, but no memory
will have been allocated and no global references will have been allocated.
If the error occurs because of invalid input, no action will have occurred.
Managing JNI Object References
JVM TI functions identify objects with JNI references
(jobject and jclass)
and their derivatives
(jthread and jthreadGroup).
References passed to
JVM TI functions can be either global or local, but they must be
strong references. All references returned by JVM TI functions are
local references--these local references are created
during the JVM TI call.
Local references are a resource that must be managed (see the
).
When threads return from native code all local references
are freed. Note that some threads, including typical
agent threads, will never return from native code.
A thread is ensured the ability to create sixteen local
references without the need for any explicit management.
For threads executing a limited number of JVM TI calls before
returning from native code
(for example, threads processing events),
it may be determined that no explicit management
is needed.
However, long running agent threads will need explicit
local reference management--usually with the JNI functions
PushLocalFrame and PopLocalFrame.
Conversely, to preserve references beyond the
return from native code, they must be converted to global references.
These rules do not apply to jmethodID and jfieldID
as they are not jobjects.
Prerequisite State for Calling Functions
Unless the function explicitly states that the agent must bring
a thread or the VM to a particular state (for example, suspended),
the JVM TI implementation is responsible for bringing the VM to a
safe and consistent state for performing the function.
Exceptions and Functions
JVM TI functions never throw exceptions; error conditions are
communicated via the
function return value.
Any existing exception state is preserved across a call to a
JVM TI function.
See the
section of the JNI specification for information on handling exceptions.
These functions provide for the allocation and deallocation of
memory used by JVM TI functionality and can be used to provide
working memory for agents.
Memory managed by JVM TI is not compatible with other memory
allocation libraries and mechanisms.
Rationale:
jlong is used for compatibility with JVMDI.
mem_ptr
unsigned char**
On return, a pointer to the beginning of the allocated memory.
If size is zero, NULL is returned.
Agent passes a pointer to a unsigned char*. On return, the unsigned char* points to a newly allocated array of size size. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Deallocate mem using the JVM TI allocator.
This function should
be used to deallocate any memory allocated and returned
by a JVM TI function
(including memory allocated with Allocate).
All allocated memory must be deallocated
or the memory cannot be reclaimed.
A pointer to the beginning of the allocated memory.
Please ignore "On return, the elements are set."
Agent passes an array of unsigned char. The incoming values of the elements of the array are ignored. On return, the elements are set.
If
mem
is
NULL, the call is ignored.
The answers are represented by the following bit vector.
Thread State Flags
Constant
Value
Description
JVMTI_THREAD_STATE_ALIVE
0x0001
Thread is alive. Zero if thread is new (not started) or terminated.
JVMTI_THREAD_STATE_TERMINATED
0x0002
Thread has completed execution.
JVMTI_THREAD_STATE_RUNNABLE
0x0004
Thread is runnable.
JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER
0x0400
Thread is waiting to enter a synchronization block/method or,
after an Object.wait(), waiting to re-enter a
synchronization block/method.
JVMTI_THREAD_STATE_WAITING
0x0080
Thread is waiting.
JVMTI_THREAD_STATE_WAITING_INDEFINITELY
0x0010
Thread is waiting without a timeout.
For example, Object.wait().
JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT
0x0020
Thread is waiting with a maximum time to wait specified.
For example, Object.wait(long).
JVMTI_THREAD_STATE_SLEEPING
0x0040
Thread is sleeping -- Thread.sleep(long).
JVMTI_THREAD_STATE_IN_OBJECT_WAIT
0x0100
Thread is waiting on an object monitor -- Object.wait.
JVMTI_THREAD_STATE_PARKED
0x0200
Thread is parked, for example: LockSupport.park,
LockSupport.parkUtil and LockSupport.parkNanos.
JVMTI_THREAD_STATE_SUSPENDED
0x100000
Thread suspended.
java.lang.Thread.suspend()
or a JVM TI suspend function
(such as SuspendThread)
has been called on the thread. If this bit
is set, the other bits refer to the thread state before suspension.
JVMTI_THREAD_STATE_INTERRUPTED
0x200000
Thread has been interrupted.
JVMTI_THREAD_STATE_IN_NATIVE
0x400000
Thread is in native code--that is, a native method is running
which has not called back into the VM or Java programming
language code.
This flag is not set when running VM compiled Java programming
language code nor is it set when running VM code or
VM support code. Native VM interface functions, such as JNI and
JVM TI functions, may be implemented as VM code.
JVMTI_THREAD_STATE_VENDOR_1
0x10000000
Defined by VM vendor.
JVMTI_THREAD_STATE_VENDOR_2
0x20000000
Defined by VM vendor.
JVMTI_THREAD_STATE_VENDOR_3
0x40000000
Defined by VM vendor.
The following definitions are used to convert JVM TI thread state
to java.lang.Thread.State style states.
Rules
There can be no more than one answer to a question, although there can be no
answer (because the answer is unknown, does not apply, or none of the answers is
correct). An answer is set only when the enclosing answers match.
That is, no more than one of
JVMTI_THREAD_STATE_RUNNABLE
JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER
JVMTI_THREAD_STATE_WAITING
can be set (a J2SETM compliant implementation will always set
one of these if JVMTI_THREAD_STATE_ALIVE is set).
And if any of these are set, the enclosing answer
JVMTI_THREAD_STATE_ALIVE is set.
No more than one of
JVMTI_THREAD_STATE_WAITING_INDEFINITELY
JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT
can be set (a J2SETM compliant implementation will always set
one of these if JVMTI_THREAD_STATE_WAITING is set).
And if either is set, the enclosing answers
JVMTI_THREAD_STATE_ALIVE and
JVMTI_THREAD_STATE_WAITING are set.
No more than one of
JVMTI_THREAD_STATE_IN_OBJECT_WAIT
JVMTI_THREAD_STATE_PARKED
JVMTI_THREAD_STATE_SLEEPING
can be set. And if any of these is set, the enclosing answers
JVMTI_THREAD_STATE_ALIVE and
JVMTI_THREAD_STATE_WAITING are set.
Also, if JVMTI_THREAD_STATE_SLEEPING is set,
then JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT is set.
If a state A is implemented using the mechanism of
state B then it is state A which
is returned by this function.
For example, if Thread.sleep(long)
is implemented using Object.wait(long)
then it is still JVMTI_THREAD_STATE_SLEEPING
which is returned.
More than one of
JVMTI_THREAD_STATE_SUSPENDED
JVMTI_THREAD_STATE_INTERRUPTED
JVMTI_THREAD_STATE_IN_NATIVE
can be set, but if any is set,
JVMTI_THREAD_STATE_ALIVE is set.
And finally,
JVMTI_THREAD_STATE_TERMINATED cannot be set unless
JVMTI_THREAD_STATE_ALIVE is not set.
The thread state representation is designed for extension in future versions
of the specification; thread state values should be used accordingly, that is
they should not be used as ordinals.
Most queries can be made by testing a single bit, if use in a switch statement is desired,
the state bits should be masked with the interesting bits.
All bits not defined above are reserved for future use.
A VM, compliant to the current specification, must set reserved bits to zero.
An agent should ignore reserved bits --
they should not be assumed to be zero and thus should not be included in comparisons.
Examples
Note that the values below exclude reserved and vendor bits.
The state of a thread blocked at a synchronized-statement would be:
Testing the State
In most cases, the thread state can be determined by testing the one bit corresponding
to that question. For example, the code to test if a thread is sleeping:
jint state;
jvmtiError err;
err = (*jvmti)->GetThreadState(jvmti, thread, &state);
if (err == JVMTI_ERROR_NONE) {
if (state & JVMTI_THREAD_STATE_SLEEPING) { ...
For waiting (that is, in Object.wait, parked, or sleeping) it would be:
if (state & JVMTI_THREAD_STATE_WAITING) { ...
For some states, more than one bit will need to be tested as is the case
when testing if a thread has not yet been started:
if ((state & (JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_TERMINATED)) == 0) { ...
To distinguish timed from untimed Object.wait:
if (state & JVMTI_THREAD_STATE_IN_OBJECT_WAIT) {
if (state & JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) {
printf("in Object.wait(long timeout)\n");
} else {
printf("in Object.wait()\n");
}
}
Relationship to java.lang.Thread.State
The thread state represented by java.lang.Thread.State
returned from java.lang.Thread.getState() is a subset of the
information returned from this function.
The corresponding java.lang.Thread.State can be determined
by using the provided conversion masks.
For example, this returns the name of the java.lang.Thread.State thread state:
err = (*jvmti)->GetThreadState(jvmti, thread, &state);
abortOnError(err);
switch (state & JVMTI_JAVA_LANG_THREAD_STATE_MASK) {
case JVMTI_JAVA_LANG_THREAD_STATE_NEW:
return "NEW";
case JVMTI_JAVA_LANG_THREAD_STATE_TERMINATED:
return "TERMINATED";
case JVMTI_JAVA_LANG_THREAD_STATE_RUNNABLE:
return "RUNNABLE";
case JVMTI_JAVA_LANG_THREAD_STATE_BLOCKED:
return "BLOCKED";
case JVMTI_JAVA_LANG_THREAD_STATE_WAITING:
return "WAITING";
case JVMTI_JAVA_LANG_THREAD_STATE_TIMED_WAITING:
return "TIMED_WAITING";
}
Get the current thread.
The current thread is the Java programming language thread which has called the function.
Note that most JVM TI functions that take a thread
as an argument will accept NULL to mean
the current thread.
On return, points to the current thread.
Agent passes a pointer to a jthread. On return, the jthread has been set. The object returned by thread_ptr is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Get all live threads.
The threads are Java programming language threads;
that is, threads that are attached to the VM.
A thread is live if java.lang.Thread.isAlive()
would return true, that is, the thread has
been started and has not yet died.
The universe of threads is determined by the context of the JVM TI
environment, which typically is all threads attached to the VM.
Note that this includes JVM TI agent threads
(see RunAgentThread).
On return, points to an array of references, one
for each running thread.
Agent passes a pointer to a jthread*. On return, the jthread* points to a newly allocated array of size *threads_count_ptr. The array should be freed with Deallocate. The objects returned by threads_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Suspend the specified thread. If the calling thread is specified,
this function will not return until some other thread calls
ResumeThread.
If the thread is currently suspended, this function
does nothing and returns an error.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Suspend the request_count
threads specified in the
request_list array.
Threads may be resumed with
ResumeThreadList or
ResumeThread.
If the calling thread is specified in the
request_list array, this function will
not return until some other thread resumes it.
Errors encountered in the suspension of a thread
are returned in the results
array, not in the return value of this function.
Threads that are currently suspended do not change state.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
An agent supplied array of
request_count elements.
On return, filled with the error code for
the suspend of the corresponding thread.
The error code will be
JVMTI_ERROR_NONE
if the thread was suspended by this call.
Possible error codes are those specified
for SuspendThread.
Agent passes an array large enough to hold request_count elements of jvmtiError. The incoming values of the elements of the array are ignored. On return, the elements are set.
Errors
This function returns either a
universal error
or one of the following errors
Resume a suspended thread.
Any threads currently suspended through
a JVM TI suspend function (eg.
SuspendThread)
or java.lang.Thread.suspend()
will resume execution;
all other threads are unaffected.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Resume the request_count
threads specified in the
request_list array.
Any thread suspended through
a JVM TI suspend function (eg.
SuspendThreadList)
or java.lang.Thread.suspend()
will resume execution.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
An agent supplied array of
request_count elements.
On return, filled with the error code for
the resume of the corresponding thread.
The error code will be
JVMTI_ERROR_NONE
if the thread was suspended by this call.
Possible error codes are those specified
for ResumeThread.
Agent passes an array large enough to hold request_count elements of jvmtiError. The incoming values of the elements of the array are ignored. On return, the elements are set.
Errors
This function returns either a
universal error
or one of the following errors
Send the specified asynchronous exception to the specified thread
(similar to java.lang.Thread.stop).
Normally, this function is used to kill the specified thread with an
instance of the exception ThreadDeath.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, filled with information describing the specified thread.
For JDK 1.1 implementations that don't
recognize context class loaders,
the context_class_loader field will be NULL.
Agent passes a pointer to a jvmtiThreadInfo. On return, the jvmtiThreadInfo has been set. The pointer returned in the field name of jvmtiThreadInfo is a newly allocated array. The array should be freed with Deallocate. The object returned in the field thread_group of jvmtiThreadInfo is a JNI local reference and must be managed.
The object returned in the field context_class_loader of jvmtiThreadInfo is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
The array of owned monitors.
Agent passes a pointer to a jobject*. On return, the jobject* points to a newly allocated array of size *owned_monitor_count_ptr. The array should be freed with Deallocate. The objects returned by owned_monitors_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
The stack depth. Corresponds to the stack depth used in the
Stack Frame functions.
That is, zero is the current frame, one is the frame which
called the current frame. And it is negative one if the
implementation cannot determine the stack depth (e.g., for
monitors acquired by JNI MonitorEnter).
The array of owned monitor depth information.
Agent passes a pointer to a jvmtiMonitorStackDepthInfo*. On return, the jvmtiMonitorStackDepthInfo* points to a newly allocated array of size *owned_monitor_depth_count_ptr. The array should be freed with Deallocate. The objects returned in the field monitor of jvmtiMonitorStackDepthInfo are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, filled with the current contended monitor, or
NULL if there is none.
Agent passes a pointer to a jobject. On return, the jobject has been set. The object returned by monitor_ptr is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Starts the execution of an agent thread. with the specified native function.
The parameter arg is forwarded on to the
start function
(specified with proc) as its single argument.
This function allows the creation of agent threads
for handling communication with another process or for handling events
without the need to load a special subclass of java.lang.Thread or
implementer of java.lang.Runnable.
Instead, the created thread can run entirely in native code.
However, the created thread does require a newly created instance
of java.lang.Thread (referenced by the argument thread) to
which it will be associated.
The thread object can be created with JNI calls.
The following common thread priorities are provided for your convenience:
Thread Priority Constants
Constant
Value
Description
JVMTI_THREAD_MIN_PRIORITY
1
Minimum possible thread priority
JVMTI_THREAD_NORM_PRIORITY
5
Normal thread priority
JVMTI_THREAD_MAX_PRIORITY
10
Maximum possible thread priority
The new thread is started as a daemon thread with the specified
priority.
If enabled, a ThreadStart event will be sent.
Since the thread has been started, the thread will be live when this function
returns, unless the thread has died immediately.
The thread group of the thread is ignored -- specifically, the thread is not
added to the thread group and the thread is not seen on queries of the thread
group at either the Java programming language or JVM TI levels.
The thread is not visible to Java programming language queries but is
included in JVM TI queries (for example,
GetAllThreads and
GetAllStackTraces).
Upon execution of proc, the new thread will be attached to the
VM--see the JNI documentation on
.
The VM stores a pointer value associated with each environment-thread
pair. This pointer value is called thread-local storage.
This value is NULL unless set with this function.
Agents can allocate memory in which they store thread specific
information. By setting thread-local storage it can then be
accessed with
GetThreadLocalStorage.
This function is called by the agent to set the value of the JVM TI
thread-local storage. JVM TI supplies to the agent a pointer-size
thread-local storage that can be used to record per-thread
information.
Retrieve from this thread.
If
thread
is
NULL, the current thread is used.
data_ptr
void**
Pointer through which the value of the thread local
storage is returned.
If thread-local storage has not been set with
SetThreadLocalStorage the returned
pointer is NULL.
Errors
This function returns either a
universal error
or one of the following errors
On return, refers to a pointer to the top-level thread group array.
Agent passes a pointer to a jthreadGroup*. On return, the jthreadGroup* points to a newly allocated array of size *group_count_ptr. The array should be freed with Deallocate. The objects returned by groups_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
On return, filled with information describing the specified
thread group.
Agent passes a pointer to a jvmtiThreadGroupInfo. On return, the jvmtiThreadGroupInfo has been set. The object returned in the field parent of jvmtiThreadGroupInfo is a JNI local reference and must be managed.
The pointer returned in the field name of jvmtiThreadGroupInfo is a newly allocated array. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
On return, points to an array of the live threads in this thread group.
Agent passes a pointer to a jthread*. On return, the jthread* points to a newly allocated array of size *thread_count_ptr. The array should be freed with Deallocate. The objects returned by threads_ptr are JNI local references and must be managed.
On return, points to an array of the active child thread groups.
Agent passes a pointer to a jthreadGroup*. On return, the jthreadGroup* points to a newly allocated array of size *group_count_ptr. The array should be freed with Deallocate. The objects returned by groups_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
These functions provide information about the stack of a thread.
Stack frames are referenced by depth.
The frame at depth zero is the current frame.
Stack frames are as described in the
of the .
That is, they correspond to method
invocations (including native methods) but do not correspond to platform native or
VM internal frames.
A JVM TI implementation may use method invocations to launch a thread and
the corresponding frames may be included in the stack as presented by these functions --
that is, there may be frames shown
deeper than main() and run().
However this presentation must be consistent across all JVM TI functionality which
uses stack frames or stack depth.
Stack frame information structure
Information about a stack frame is returned in this structure.
Get information about the stack of a thread.
If max_frame_count is less than the depth of the stack,
the max_frame_count topmost frames are returned,
otherwise the entire stack is returned.
The topmost frames, those most recently invoked, are at the beginning of the returned buffer.
The following example causes up to five of the topmost frames
to be returned and (if there are any frames) the currently
executing method name to be printed.
The thread need not be suspended
to call this function.
The GetLineNumberTable
function can be used to map locations to line numbers. Note that
this mapping can be done lazily.
Begin retrieving frames at this depth.
If non-negative, count from the current frame,
the first frame retrieved is at depth start_depth.
For example, if zero, start from the current frame; if one, start from the
caller of the current frame; if two, start from the caller of the
caller of the current frame; and so on.
If negative, count from below the oldest frame,
the first frame retrieved is at depth stackDepth + start_depth,
where stackDepth is the count of frames on the stack.
For example, if negative one, only the oldest frame is retrieved;
if negative two, start from the frame called by the oldest frame.
On return, this agent allocated buffer is filled
with stack frame information.
Agent passes an array large enough to hold max_frame_count elements of jvmtiFrameInfo. The incoming values of the elements of the array are ignored. On return, *count_ptr of the elements are set.
On return, points to the number of records filled in.
For non-negative start_depth, this will be
min(max_frame_count, stackDepth - start_depth).
For negative start_depth, this will be
min(max_frame_count, -start_depth).
Agent passes a pointer to a jint. On return, the jint has been set.
Errors
This function returns either a
universal error
or one of the following errors
Get information about the stacks of all live threads
(including agent threads).
If max_frame_count is less than the depth of a stack,
the max_frame_count topmost frames are returned for that thread,
otherwise the entire stack is returned.
The topmost frames, those most recently invoked, are at the beginning of the returned buffer.
All stacks are collected simultaneously, that is, no changes will occur to the
thread state or stacks between the sampling of one thread and the next.
The threads need not be suspended.
jvmtiStackInfo *stack_info;
jint thread_count;
int ti;
jvmtiError err;
err = (*jvmti)->GetAllStackTraces(jvmti, MAX_FRAMES, &stack_info, &thread_count);
if (err != JVMTI_ERROR_NONE) {
...
}
for (ti = 0; ti < thread_count; ++ti) {
jvmtiStackInfo *infop = &stack_info[ti];
jthread thread = infop->thread;
jint state = infop->state;
jvmtiFrameInfo *frames = infop->frame_buffer;
int fi;
myThreadAndStatePrinter(thread, state);
for (fi = 0; fi < infop->frame_count; fi++) {
myFramePrinter(frames[fi].method, frames[fi].location);
}
}
/* this one Deallocate call frees all data allocated by GetAllStackTraces */
err = (*jvmti)->Deallocate(jvmti, stack_info);
On return, this buffer is filled
with stack information for each thread.
The number of jvmtiStackInfo records is determined
by thread_count_ptr.
Note that this buffer is allocated to include the jvmtiFrameInfo
buffers pointed to by jvmtiStackInfo.frame_buffer.
These buffers must not be separately deallocated.
Agent passes a pointer to a jvmtiStackInfo*. On return, the jvmtiStackInfo* points to a newly allocated array. The array should be freed with Deallocate. The objects returned in the field thread of jvmtiStackInfo are JNI local references and must be managed.
Get information about the stacks of the supplied threads.
If max_frame_count is less than the depth of a stack,
the max_frame_count topmost frames are returned for that thread,
otherwise the entire stack is returned.
The topmost frames, those most recently invoked, are at the beginning of the returned buffer.
All stacks are collected simultaneously, that is, no changes will occur to the
thread state or stacks between the sampling one thread and the next.
The threads need not be suspended.
If a thread has not yet started or terminates before the stack information is collected,
a zero length stack (jvmtiStackInfo.frame_count will be zero)
will be returned and the thread jvmtiStackInfo.state can be checked.
See the example for the similar function
GetAllStackTraces.
On return, this buffer is filled
with stack information for each thread.
The number of jvmtiStackInfo records is determined
by thread_count.
Note that this buffer is allocated to include the jvmtiFrameInfo
buffers pointed to by jvmtiStackInfo.frame_buffer.
These buffers must not be separately deallocated.
Agent passes a pointer to a jvmtiStackInfo*. On return, the jvmtiStackInfo* points to a newly allocated array of size *thread_count. The array should be freed with Deallocate. The objects returned in the field thread of jvmtiStackInfo are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Get the number of frames currently in the specified thread's call stack.
If this function is called for a thread actively executing bytecodes (for example,
not the current thread and not suspended), the information returned is transient.
Pop the current frame of thread's stack.
Popping a frame takes you to the previous frame.
When the thread is resumed, the execution
state of the thread is reset to the state
immediately before the called method was invoked.
That is (using the terminology):
the current frame is discarded as the previous frame becomes the current one
the operand stack is restored--the argument values are added back
and if the invoke was not invokestatic,
objectref is added back as well
the Java virtual machine PC is restored to the opcode
of the invoke instruction
Note however, that any changes to the arguments, which
occurred in the called method, remain;
when execution continues, the first instruction to
execute will be the invoke.
Between calling PopFrame and resuming the
thread the state of the stack is undefined.
To pop frames beyond the first,
these three steps must be repeated:
suspend the thread via an event (step, breakpoint, ...)
call PopFrame
resume the thread
A lock acquired by calling the called method
(if it is a synchronized method)
and locks acquired by entering synchronized
blocks within the called method are released.
Note: this does not apply to native locks or
java.util.concurrent.locks locks.
Finally blocks are not executed.
Changes to global state are not addressed and thus remain changed.
The specified thread must be suspended (which implies it cannot be the current thread).
Both the called method and calling method must be non-native Java programming
language methods.
No JVM TI events are generated by this function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the index of the currently
executing instruction.
Is set to -1 if the frame is executing
a native method.
Agent passes a pointer to a jlocation. On return, the jlocation has been set.
Errors
This function returns either a
universal error
or one of the following errors
When the frame that is currently at depth
is popped from the stack, generate a
FramePop event. See the
FramePop event for details.
Only frames corresponding to non-native Java programming language
methods can receive notification.
The specified thread must either be the current thread
or the thread must be suspended.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
These functions allow an agent to force a method
to return at any point during its execution.
The method which will return early is referred to as the called method.
The called method is the current method
(as defined by the
of the )
for the specified thread at
the time the function is called.
The specified thread must be suspended or must be the current thread.
The return occurs when execution of Java programming
language code is resumed on this thread.
Between calling one of these functions and resumption
of thread execution, the state of the stack is undefined.
No further instructions are executed in the called method.
Specifically, finally blocks are not executed.
Note: this can cause inconsistent states in the application.
A lock acquired by calling the called method
(if it is a synchronized method)
and locks acquired by entering synchronized
blocks within the called method are released.
Note: this does not apply to native locks or
java.util.concurrent.locks locks.
Events, such as MethodExit,
are generated as they would be in a normal return.
The called method must be a non-native Java programming
language method.
Forcing return on a thread with only one frame on the
stack causes the thread to exit when resumed.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
These functions are used to analyze the heap.
Functionality includes the ability to view the objects in the
heap and to tag these objects.
Object Tags
A tag is a value associated with an object.
Tags are explicitly set by the agent using the
SetTag function or by
callback functions such as jvmtiHeapIterationCallback.
Tags are local to the environment; that is, the tags of one
environment are not visible in another.
Tags are jlong values which can be used
simply to mark an object or to store a pointer to more detailed
information. Objects which have not been tagged have a
tag of zero.
Setting a tag to zero makes the object untagged.
Heap Callback Functions
Heap functions which iterate through the heap and recursively
follow object references use agent supplied callback functions
to deliver the information.
These heap callback functions must adhere to the following restrictions --
These callbacks must not use JNI functions.
These callbacks must not use JVM TI functions except
callback safe functions which
specifically allow such use (see the raw monitor, memory management,
and environment local storage functions).
An implementation may invoke a callback on an internal thread or
the thread which called the iteration function.
Heap callbacks are single threaded -- no more than one callback will
be invoked at a time.
The Heap Filter Flags can be used to prevent reporting
based on the tag status of an object or its class.
If no flags are set (the jint is zero), objects
will not be filtered out.
Heap Filter Flags
Constant
Value
Description
JVMTI_HEAP_FILTER_TAGGED
0x4
Filter out tagged objects. Objects which are tagged are not included.
JVMTI_HEAP_FILTER_UNTAGGED
0x8
Filter out untagged objects. Objects which are not tagged are not included.
JVMTI_HEAP_FILTER_CLASS_TAGGED
0x10
Filter out objects with tagged classes. Objects whose class is tagged are not included.
JVMTI_HEAP_FILTER_CLASS_UNTAGGED
0x20
Filter out objects with untagged classes. Objects whose class is not tagged are not included.
The Heap Visit Control Flags are returned by the heap callbacks
and can be used to abort the iteration. For the
Heap
Reference Callback, it can also be used
to prune the graph of traversed references
(JVMTI_VISIT_OBJECTS is not set).
Heap Visit Control Flags
Constant
Value
Description
JVMTI_VISIT_OBJECTS
0x100
If we are visiting an object and if this callback
was initiated by FollowReferences,
traverse the references of this object.
Otherwise ignored.
Reference from an object to the value of one of its instance fields.
JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT
3
Reference from an array to one of its elements.
JVMTI_HEAP_REFERENCE_CLASS_LOADER
4
Reference from a class to its class loader.
JVMTI_HEAP_REFERENCE_SIGNERS
5
Reference from a class to its signers array.
JVMTI_HEAP_REFERENCE_PROTECTION_DOMAIN
6
Reference from a class to its protection domain.
JVMTI_HEAP_REFERENCE_INTERFACE
7
Reference from a class to one of its interfaces.
Note: interfaces are defined via a constant pool reference,
so the referenced interfaces may also be reported with a
JVMTI_HEAP_REFERENCE_CONSTANT_POOL reference kind.
JVMTI_HEAP_REFERENCE_STATIC_FIELD
8
Reference from a class to the value of one of its static fields.
JVMTI_HEAP_REFERENCE_CONSTANT_POOL
9
Reference from a class to a resolved entry in the constant pool.
JVMTI_HEAP_REFERENCE_SUPERCLASS
10
Reference from a class to its superclass.
A callback is bot sent if the superclass is java.lang.Object.
Note: loaded classes define superclasses via a constant pool
reference, so the referenced superclass may also be reported with
a JVMTI_HEAP_REFERENCE_CONSTANT_POOL reference kind.
JVMTI_HEAP_REFERENCE_JNI_GLOBAL
21
Heap root reference: JNI global reference.
JVMTI_HEAP_REFERENCE_SYSTEM_CLASS
22
Heap root reference: System class.
JVMTI_HEAP_REFERENCE_MONITOR
23
Heap root reference: monitor.
JVMTI_HEAP_REFERENCE_STACK_LOCAL
24
Heap root reference: local variable on the stack.
JVMTI_HEAP_REFERENCE_JNI_LOCAL
25
Heap root reference: JNI local reference.
JVMTI_HEAP_REFERENCE_THREAD
26
Heap root reference: Thread.
JVMTI_HEAP_REFERENCE_OTHER
27
Heap root reference: other heap root reference.
Definitions for the single character type descriptors of
primitive types.
Primitive Type Enumeration (jvmtiPrimitiveType)
Constant
Value
Description
JVMTI_PRIMITIVE_TYPE_BOOLEAN
90
'Z' - Java programming language boolean - JNI jboolean
JVMTI_PRIMITIVE_TYPE_BYTE
66
'B' - Java programming language byte - JNI jbyte
JVMTI_PRIMITIVE_TYPE_CHAR
67
'C' - Java programming language char - JNI jchar
JVMTI_PRIMITIVE_TYPE_SHORT
83
'S' - Java programming language short - JNI jshort
JVMTI_PRIMITIVE_TYPE_INT
73
'I' - Java programming language int - JNI jint
JVMTI_PRIMITIVE_TYPE_LONG
74
'J' - Java programming language long - JNI jlong
JVMTI_PRIMITIVE_TYPE_FLOAT
70
'F' - Java programming language float - JNI jfloat
JVMTI_PRIMITIVE_TYPE_DOUBLE
68
'D' - Java programming language double - JNI jdouble
Reference information structure for Field references
For JVMTI_HEAP_REFERENCE_FIELD, the
referrer object is not a class or an inteface.
In this case, index is the index of the field
in the class of the referrer object.
This class is referred to below as C.
For JVMTI_HEAP_REFERENCE_STATIC_FIELD,
the referrer object is a class (referred to below as C)
or an interface (referred to below as I).
In this case, index is the index of the field in
that class or interface.
If the referrer object is not an interface, then the field
indices are determined as follows:
make a list of all the fields in C and its
superclasses, starting with all the fields in
java.lang.Object and ending with all the
fields in C.
Within this list, put
the fields for a given class in the order returned by
GetClassFields.
Assign the fields in this list indices
n, n+1, ..., in order, where n
is the count of the fields in all the interfaces
implemented by C.
Note that C implements all interfaces
directly implemented by its superclasses; as well
as all superinterfaces of these interfaces.
If the referrer object is an interface, then the field
indices are determined as follows:
make a list of the fields directly declared in
I.
Within this list, put
the fields in the order returned by
GetClassFields.
Assign the fields in this list indices
n, n+1, ..., in order, where n
is the count of the fields in all the superinterfaces
of I.
All fields are included in this computation, regardless of
field modifier (static, public, private, etc).
For example, given the following classes and interfaces:
interface I0 {
int p = 0;
}
interface I1 extends I0 {
int x = 1;
}
interface I2 extends I0 {
int y = 2;
}
class C1 implements I1 {
public static int a = 3;
private int b = 4;
}
class C2 extends C1 implements I2 {
static int q = 5;
final int r = 6;
}
Assume that GetClassFields called on
C1 returns the fields of C1 in the
order: a, b; and that the fields of C2 are
returned in the order: q, r.
An instance of class C1 will have the
following field indices:
a
2
The count of the fields in the interfaces
implemented by C1 is two (n=2):
p of I0
and x of I1.
b
3
the subsequent index.
The class C1 will have the same field indices.
An instance of class C2 will have the
following field indices:
a
3
The count of the fields in the interfaces
implemented by C2 is three (n=3):
p of I0,
x of I1 and y of I2
(an interface of C2). Note that the field p
of I0 is only included once.
b
4
the subsequent index to "a".
q
5
the subsequent index to "b".
r
6
the subsequent index to "q".
The class C2 will have the same field indices.
Note that a field may have a different index depending on the
object that is viewing it -- for example field "a" above.
Note also: not all field indices may be visible from the
callbacks, but all indices are shown for illustrative purposes.
The interface I1 will have the
following field indices:
x
1
The count of the fields in the superinterfaces
of I1 is one (n=1):
p of I0.
Reference information structure for Array references
Rationale:
The heap dumping functionality (below) uses a callback
for each object. While it would seem that a buffered approach
would provide better throughput, tests do
not show this to be the case--possibly due to locality of
memory reference or array access overhead.
Agent supplied callback function.
Describes (but does not pass in) an object in the heap.
This function should return a bit vector of the desired
visit control flags.
This will determine if the entire iteration should be aborted
(the JVMTI_VISIT_OBJECTS flag is ignored).
See the heap callback
function restrictions.
The tag of the class of object (zero if the class is not tagged).
If the object represents a runtime class,
the class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
The object tag value, or zero if the object is not tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
Agent supplied callback function.
Describes a reference from an object or the VM (the referrer) to another object
(the referree) or a heap root to a referree.
This function should return a bit vector of the desired
visit control flags.
This will determine if the objects referenced by the referree
should be visited or if the entire iteration should be aborted.
See the heap callback
function restrictions.
The tag of the class of referree object (zero if the class is not tagged).
If the referree object represents a runtime class,
the class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
The tag of the class of the referrer object (zero if the class is not tagged
or the referree is a heap root). If the referrer object represents a runtime
class, the referrer_class_tag is the tag associated with
the java.lang.Class
(zero if java.lang.Class is not tagged).
Points to the referree object tag value, or zero if the object is not
tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
Points to the tag of the referrer object, or
points to the zero if the referrer
object is not tagged.
NULL if the referrer in not an object (that is,
this callback is reporting a heap root).
To set the tag value to be associated with the referrer object
the agent sets the jlong pointed to by the parameter.
If this callback is reporting a reference from an object to itself,
referrer_tag_ptr == tag_ptr.
Agent supplied callback function which
describes a primitive field of an object (the object).
A primitive field is a field whose type is a primitive type.
This callback will describe a static field if the object is a class,
and otherwise will describe an instance field.
This function should return a bit vector of the desired
visit control flags.
This will determine if the entire iteration should be aborted
(the JVMTI_VISIT_OBJECTS flag is ignored).
See the heap callback
function restrictions.
The tag of the class of the object (zero if the class is not tagged).
If the object represents a runtime class, the
object_class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
Points to the tag of the object, or zero if the object is not
tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
Agent supplied callback function.
Describes the values in an array of a primitive type.
This function should return a bit vector of the desired
visit control flags.
This will determine if the entire iteration should be aborted
(the JVMTI_VISIT_OBJECTS flag is ignored).
See the heap callback
function restrictions.
Points to the tag of the array object, or zero if the object is not
tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
Agent supplied callback function.
Describes the value of a java.lang.String.
This function should return a bit vector of the desired
visit control flags.
This will determine if the entire iteration should be aborted
(the JVMTI_VISIT_OBJECTS flag is ignored).
See the heap callback
function restrictions.
Points to the tag of the String object, or zero if the object is not
tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
This function initiates a traversal over the objects that are
directly and indirectly reachable from the specified object or,
if initial_object is not specified, all objects
reachable from the heap roots.
The heap root are the set of system classes,
JNI globals, references from thread stacks, and other objects used as roots
for the purposes of garbage collection.
This function operates by traversing the reference graph.
Let A, B, ... represent objects.
When a reference from A to B is traversed,
when a reference from a heap root to B is traversed,
or when B is specified as the initial_object,
then B is said to be visited.
A reference from A to B is not traversed until A
is visited.
References are reported in the same order that the references are traversed.
Object references are reported by invoking the agent supplied
callback function jvmtiHeapReferenceCallback.
In a reference from A to B, A is known
as the referrer and B as the referree.
The callback is invoked exactly once for each reference from a referrer;
this is true even if there are reference cycles or multiple paths to
the referrer.
There may be more than one reference between a referrer and a referree,
each reference is reported.
These references may be distinguished by examining the
reference_kind
and
reference_info
parameters of the jvmtiHeapReferenceCallback callback.
This function reports a Java programming language view of object references,
not a virtual machine implementation view. The following object references
are reported when they are non-null:
Instance objects report references to each non-primitive instance fields
(including inherited fields).
Instance objects report a reference to the object type (class).
Classes report a reference to the superclass and directly
implemented/extended interfaces.
Classes report a reference to the class loader, protection domain,
signers, and resolved entries in the constant pool.
Classes report a reference to each directly declared non-primitive
static field.
Arrays report a reference to the array type (class) and each
array element.
Primitive arrays report a reference to the array type.
This function can also be used to examine primitive (non-object) values.
The primitive value of an array or String
is reported after the object has been visited;
it is reported by invoking the agent supplied callback function
jvmtiArrayPrimitiveValueCallback or
jvmtiStringPrimitiveValueCallback.
A primitive field
is reported after the object with that field is visited;
it is reported by invoking the agent supplied callback function
jvmtiPrimitiveFieldCallback.
Whether a callback is provided or is NULL only determines
whether the callback will be invoked, it does not influence
which objects are visited nor does it influence whether other callbacks
will be invoked.
However, the
visit control flags
returned by jvmtiHeapReferenceCallback
do determine if the objects referenced by the
current object as visited.
The heap filter flags
and klass provided as parameters to this function
do not control which objects are visited but they do control which
objects and primitive values are reported by the callbacks.
For example, if the only callback that was set is
array_primitive_value_callback and klass
is set to the array of bytes class, then only arrays of byte will be
reported.
The table below summarizes this:
During the execution of this function the state of the heap
does not change: no objects are allocated, no objects are
garbage collected, and the state of objects (including
held values) does not change.
As a result, threads executing Java
programming language code, threads attempting to resume the
execution of Java programming language code, and threads
attempting to execute JNI functions are typically stalled.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
This bit vector of
heap filter flags.
restricts the objects for which the callback function is called.
This applies to both the object and primitive callbacks.
Callbacks are only reported when the object is an instance of
this class.
Objects which are instances of a subclass of klass
are not reported.
If klass is an interface, no objects are reported.
This applies to both the object and primitive callbacks.
If
klass
is
NULL, callbacks are not limited to instances of a particular
class.
Initiate an iteration over all objects in the heap.
This includes both reachable and
unreachable objects. Objects are visited in no particular order.
Heap objects are reported by invoking the agent supplied
callback function jvmtiHeapIterationCallback.
References between objects are not reported.
If only reachable objects are desired, or if object reference information
is needed, use FollowReferences.
This function can also be used to examine primitive (non-object) values.
The primitive value of an array or String
is reported after the object has been visited;
it is reported by invoking the agent supplied callback function
jvmtiArrayPrimitiveValueCallback or
jvmtiStringPrimitiveValueCallback.
A primitive field
is reported after the object with that field is visited;
it is reported by invoking the agent supplied
callback function
jvmtiPrimitiveFieldCallback.
Unless the iteration is aborted by the
Heap Visit Control Flags
returned by a callback, all objects in the heap are visited.
Whether a callback is provided or is NULL only determines
whether the callback will be invoked, it does not influence
which objects are visited nor does it influence whether other callbacks
will be invoked.
The heap filter flags
and klass provided as parameters to this function
do not control which objects are visited but they do control which
objects and primitive values are reported by the callbacks.
For example, if the only callback that was set is
array_primitive_value_callback and klass
is set to the array of bytes class, then only arrays of byte will be
reported. The table below summarizes this (contrast this with
FollowReferences):
During the execution of this function the state of the heap
does not change: no objects are allocated, no objects are
garbage collected, and the state of objects (including
held values) does not change.
As a result, threads executing Java
programming language code, threads attempting to resume the
execution of Java programming language code, and threads
attempting to execute JNI functions are typically stalled.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
This bit vector of
heap filter flags.
restricts the objects for which the callback function is called.
This applies to both the object and primitive callbacks.
Callbacks are only reported when the object is an instance of
this class.
Objects which are instances of a subclass of klass
are not reported.
If klass is an interface, no objects are reported.
This applies to both the object and primitive callbacks.
If
klass
is
NULL, callbacks are not limited to instances of a particular class.
Retrieve the tag associated with an object.
The tag is a long value typically used to store a
unique identifier or pointer to object information.
The tag is set with
SetTag.
Objects for which no tags have been set return a
tag value of zero.
may
only be called during the start or the live
phase
No
106
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Set the tag associated with an object.
The tag is a long value typically used to store a
unique identifier or pointer to object information.
The tag is visible with
GetTag.
may
only be called during the start or the live
phase
No
107
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Returns the array of objects with any of the tags
in tags.
Agent passes a pointer to a jobject*. On return, the jobject* points to a newly allocated array of size *count_ptr. The array should be freed with Deallocate.
If
object_result_ptr
is
NULL, this information is not returned.
The objects returned by object_result_ptr are JNI local references and must be managed.
For each object in object_result_ptr,
return the tag at the corresponding index.
Agent passes a pointer to a jlong*. On return, the jlong* points to a newly allocated array of size *count_ptr. The array should be freed with Deallocate.
If
tag_result_ptr
is
NULL, this information is not returned.
Errors
This function returns either a
universal error
or one of the following errors
Force the VM to perform a garbage collection.
The garbage collection is as complete as possible.
This function does not cause finalizers to be run.
This function does not return until the garbage collection
is finished.
Although garbage collection is as complete
as possible there is no guarantee that all
ObjectFree
events will have been
sent by the time that this function
returns. In particular, an object may be
prevented from being freed because it
is awaiting finalization.
These functions and data types were introduced in the original
JVM TI version 1.0 and have been superseded by more
powerful and flexible versions
which:
Allow access to primitive values (the value of Strings, arrays,
and primitive fields)
Allow the tag of the referrer to be set, thus enabling more
efficient localized reference graph building
Provide more extensive filtering abilities
Are extensible, allowing their abilities to grow in future versions of JVM TI
Reference from an object to the value of one of its instance fields.
For references of this kind the referrer_index
parameter to the
jvmtiObjectReferenceCallback is the index of the
the instance field. The index is based on the order of all the
object's fields. This includes all fields of the directly declared
static and instance fields in the class, and includes all fields (both
public and private) fields declared in superclasses and superinterfaces.
The index is thus calculated by summing the index of the field in the directly
declared class (see GetClassFields), with the total
number of fields (both public and private) declared in all superclasses
and superinterfaces. The index starts at zero.
JVMTI_REFERENCE_ARRAY_ELEMENT
3
Reference from an array to one of its elements.
For references of this kind the referrer_index
parameter to the
jvmtiObjectReferenceCallback is the array index.
JVMTI_REFERENCE_CLASS_LOADER
4
Reference from a class to its class loader.
JVMTI_REFERENCE_SIGNERS
5
Reference from a class to its signers array.
JVMTI_REFERENCE_PROTECTION_DOMAIN
6
Reference from a class to its protection domain.
JVMTI_REFERENCE_INTERFACE
7
Reference from a class to one of its interfaces.
JVMTI_REFERENCE_STATIC_FIELD
8
Reference from a class to the value of one of its static fields.
For references of this kind the referrer_index
parameter to the
jvmtiObjectReferenceCallback is the index of the
the static field. The index is based on the order of all the
object's fields. This includes all fields of the directly declared
static and instance fields in the class, and includes all fields (both
public and private) fields declared in superclasses and superinterfaces.
The index is thus calculated by summing the index of the field in the directly
declared class (see GetClassFields), with the total
number of fields (both public and private) declared in all superclasses
and superinterfaces. The index starts at zero.
Note: this definition differs from that in the JVM TI 1.0 Specification.
Rationale:
No known implementations used the 1.0 definition.
JVMTI_REFERENCE_CONSTANT_POOL
9
Reference from a class to a resolved entry in the constant pool.
For references of this kind the referrer_index
parameter to the
jvmtiObjectReferenceCallback is the index into
constant pool table of the class, starting at 1. See the
of the
Iteration Control Enumeration (jvmtiIterationControl)
Constant
Value
Description
JVMTI_ITERATION_CONTINUE
1
Continue the iteration.
If this is a reference iteration, follow the references of this object.
JVMTI_ITERATION_IGNORE
2
Continue the iteration.
If this is a reference iteration, ignore the references of this object.
Agent supplied callback function.
Describes (but does not pass in) an object in the heap.
Return value should be JVMTI_ITERATION_CONTINUE to continue iteration,
or JVMTI_ITERATION_ABORT to stop iteration.
See the heap callback
function restrictions.
The tag of the class of object (zero if the class is not tagged).
If the object represents a runtime class,
the class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
The object tag value, or zero if the object is not tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
user_data
void*
The user supplied data that was passed into the iteration function.
Agent supplied callback function.
Describes (but does not pass in) an object that is a root for the purposes
of garbage collection.
Return value should be JVMTI_ITERATION_CONTINUE to continue iteration,
JVMTI_ITERATION_IGNORE to continue iteration without pursuing
references from referree object or JVMTI_ITERATION_ABORT to stop iteration.
See the heap callback
function restrictions.
The tag of the class of object (zero if the class is not tagged).
If the object represents a runtime class, the class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
The object tag value, or zero if the object is not tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
user_data
void*
The user supplied data that was passed into the iteration function.
Agent supplied callback function.
Describes (but does not pass in) an object on the stack that is a root for
the purposes of garbage collection.
Return value should be JVMTI_ITERATION_CONTINUE to continue iteration,
JVMTI_ITERATION_IGNORE to continue iteration without pursuing
references from referree object or JVMTI_ITERATION_ABORT to stop iteration.
See the heap callback
function restrictions.
The tag of the class of object (zero if the class is not tagged).
If the object represents a runtime class, the class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
The object tag value, or zero if the object is not tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
Agent supplied callback function.
Describes a reference from an object (the referrer) to another object
(the referree).
Return value should be JVMTI_ITERATION_CONTINUE to continue iteration,
JVMTI_ITERATION_IGNORE to continue iteration without pursuing
references from referree object or JVMTI_ITERATION_ABORT to stop iteration.
See the heap callback
function restrictions.
The tag of the class of referree object (zero if the class is not tagged).
If the referree object represents a runtime class,
the class_tag is the tag
associated with java.lang.Class
(zero if java.lang.Class is not tagged).
The referree object tag value, or zero if the object is not
tagged.
To set the tag value to be associated with the object
the agent sets the jlong pointed to by the parameter.
For references of type JVMTI_REFERENCE_FIELD or
JVMTI_REFERENCE_STATIC_FIELD the index
of the field in the referrer object. The index is based on the
order of all the object's fields - see JVMTI_REFERENCE_FIELD
or JVMTI_REFERENCE_STATIC_FIELD
for further description.
For references of type JVMTI_REFERENCE_ARRAY_ELEMENT
the array index - see
JVMTI_REFERENCE_ARRAY_ELEMENT for further description.
For references of type JVMTI_REFERENCE_CONSTANT_POOL
the index into the constant pool of the class - see
JVMTI_REFERENCE_CONSTANT_POOL for further
description.
For references of other kinds the referrer_index is
-1.
user_data
void*
The user supplied data that was passed into the iteration function.
This function iterates over all objects that are directly
and indirectly reachable from the specified object.
For each object A (known
as the referrer) with a reference to object B the specified
callback function is called to describe the object reference.
The callback is called exactly once for each reference from a referrer;
this is true even if there are reference cycles or multiple paths to
the referrer.
There may be more than one reference between a referrer and a referree,
These may be distinguished by the
jvmtiObjectReferenceCallback.reference_kind and
jvmtiObjectReferenceCallback.referrer_index.
The callback for an object will always occur after the callback for
its referrer.
See FollowReferences for the object
references which are reported.
During the execution of this function the state of the heap
does not change: no objects are allocated, no objects are
garbage collected, and the state of objects (including
held values) does not change.
As a result, threads executing Java
programming language code, threads attempting to resume the
execution of Java programming language code, and threads
attempting to execute JNI functions are typically stalled.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
This function iterates over the root objects and all objects that
are directly and indirectly reachable from the root objects.
The root objects comprise the set of system classes,
JNI globals, references from thread stacks, and other objects used as roots
for the purposes of garbage collection.
For each root the heap_root_callback
or stack_ref_callback callback is called.
An object can be a root object for more than one reason and in that case
the appropriate callback is called for each reason.
For each object reference the object_ref_callback
callback function is called to describe the object reference.
The callback is called exactly once for each reference from a referrer;
this is true even if there are reference cycles or multiple paths to
the referrer.
There may be more than one reference between a referrer and a referree,
These may be distinguished by the
jvmtiObjectReferenceCallback.reference_kind and
jvmtiObjectReferenceCallback.referrer_index.
The callback for an object will always occur after the callback for
its referrer.
See FollowReferences for the object
references which are reported.
Roots are always reported to the profiler before any object references
are reported. In other words, the object_ref_callback
callback will not be called until the appropriate callback has been called
for all roots. If the object_ref_callback callback is
specified as NULL then this function returns after
reporting the root objects to the profiler.
During the execution of this function the state of the heap
does not change: no objects are allocated, no objects are
garbage collected, and the state of objects (including
held values) does not change.
As a result, threads executing Java
programming language code, threads attempting to resume the
execution of Java programming language code, and threads
attempting to execute JNI functions are typically stalled.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
The callback function to be called for each heap root of type
JVMTI_HEAP_ROOT_JNI_GLOBAL,
JVMTI_HEAP_ROOT_SYSTEM_CLASS,
JVMTI_HEAP_ROOT_MONITOR,
JVMTI_HEAP_ROOT_THREAD, or
JVMTI_HEAP_ROOT_OTHER.
If
heap_root_callback
is
NULL, do not report heap roots.
The callback function to be called for each heap root of
JVMTI_HEAP_ROOT_STACK_LOCAL or
JVMTI_HEAP_ROOT_JNI_LOCAL.
If
stack_ref_callback
is
NULL, do not report stack references.
Iterate over all objects in the heap. This includes both reachable and
unreachable objects.
The object_filter parameter indicates the
objects for which the callback function is called. If this parameter
is JVMTI_HEAP_OBJECT_TAGGED then the callback will only be
called for every object that is tagged. If the parameter is
JVMTI_HEAP_OBJECT_UNTAGGED then the callback will only be
for objects that are not tagged. If the parameter
is JVMTI_HEAP_OBJECT_EITHER then the callback will be
called for every object in the heap, irrespective of whether it is
tagged or not.
During the execution of this function the state of the heap
does not change: no objects are allocated, no objects are
garbage collected, and the state of objects (including
held values) does not change.
As a result, threads executing Java
programming language code, threads attempting to resume the
execution of Java programming language code, and threads
attempting to execute JNI functions are typically stalled.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Iterate over all objects in the heap that are instances of the specified class.
This includes direct instances of the specified class and
instances of all subclasses of the specified class.
This includes both reachable and unreachable objects.
The object_filter parameter indicates the
objects for which the callback function is called. If this parameter
is JVMTI_HEAP_OBJECT_TAGGED then the callback will only be
called for every object that is tagged. If the parameter is
JVMTI_HEAP_OBJECT_UNTAGGED then the callback will only be
called for objects that are not tagged. If the parameter
is JVMTI_HEAP_OBJECT_EITHER then the callback will be
called for every object in the heap, irrespective of whether it is
tagged or not.
During the execution of this function the state of the heap
does not change: no objects are allocated, no objects are
garbage collected, and the state of objects (including
held values) does not change.
As a result, threads executing Java
programming language code, threads attempting to resume the
execution of Java programming language code, and threads
attempting to execute JNI functions are typically stalled.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
These functions are used to retrieve or set the value of a local variable.
The variable is identified by the depth of the frame containing its
value and the variable's slot number within that frame.
The mapping of variables to
slot numbers can be obtained with the function
GetLocalVariableTable.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the variable's value.
Agent passes a pointer to a jobject. On return, the jobject has been set. The object returned by value_ptr is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Set a breakpoint at the instruction indicated by
method and location.
An instruction can only have one breakpoint.
Whenever the designated instruction is about to be executed, a
Breakpoint event is generated.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Generate a FieldAccess event
when the field specified
by klass and
field is about to be accessed.
An event will be generated for each access of the field
until it is canceled with
ClearFieldAccessWatch.
Field accesses from Java programming language code or from JNI code are watched,
fields modified by other means are not watched.
Note that JVM TI users should be aware that their own field accesses
will trigger the watch.
A field can only have one field access watch set.
Modification of a field is not considered an access--use
SetFieldModificationWatch
to monitor modifications.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Generate a FieldModification event
when the field specified
by klass and
field is about to be modified.
An event will be generated for each modification of the field
until it is canceled with
ClearFieldModificationWatch.
Field modifications from Java programming language code or from JNI code are watched,
fields modified by other means are not watched.
Note that JVM TI users should be aware that their own field modifications
will trigger the watch.
A field can only have one field modification watch set.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Return an array of all classes loaded in the virtual machine.
The number of classes in the array is returned via
class_count_ptr, and the array itself via
classes_ptr.
Array classes of all types (including arrays of primitive types) are
included in the returned list. Primitive classes (for example,
java.lang.Integer.TYPE) are not included in this list.
On return, points to an array of references, one
for each class.
Agent passes a pointer to a jclass*. On return, the jclass* points to a newly allocated array of size *class_count_ptr. The array should be freed with Deallocate. The objects returned by classes_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
Returns an array of those classes for which this class loader has
been recorded as an initiating loader. Each
class in the returned array was created by this class loader,
either by defining it directly or by delegation to another class loader.
See the
of the .
For JDK version 1.1 implementations that don't
recognize the distinction between initiating and defining class loaders,
this function should return all classes loaded in the virtual machine.
The number of classes in the array is returned via
class_count_ptr, and the array itself via
classes_ptr.
On return, points to an array of references, one
for each class.
Agent passes a pointer to a jclass*. On return, the jclass* points to a newly allocated array of size *class_count_ptr. The array should be freed with Deallocate. The objects returned by classes_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
For the class indicated by klass, return the
and the generic signature of the class.
For example, java.util.List is "Ljava/util/List;"
and int[] is "[I"
The returned name for primitive classes
is the type signature character of the corresponding primitive type.
For example, java.lang.Integer.TYPE is "I".
On return, points to the JNI type signature of the class, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
signature_ptr
is
NULL, the signature is not returned.
generic_ptr
char
**
On return, points to the generic signature of the class, encoded as a
modified UTF-8 string.
If there is no generic signature attribute for the class, then,
on return, points to NULL.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
generic_ptr
is
NULL, the generic signature is not returned.
Errors
This function returns either a
universal error
or one of the following errors
On return, points to the current state of this class as one or
more of the class status flags.
Agent passes a pointer to a jint. On return, the jint has been set.
Errors
This function returns either a
universal error
or one of the following errors
For the class indicated by klass, return the source file
name via source_name_ptr. The returned string
is a file name only and never contains a directory name.
For primitive classes (for example, java.lang.Integer.TYPE)
and for arrays this function returns
JVMTI_ERROR_ABSENT_INFORMATION.
may
only be called during the start or the live
phase
No
50
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the class's source file name, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
For the class indicated by klass, return the access
flags
via modifiers_ptr.
Access flags are defined in the
of the .
If the class is an array class, then its public, private, and protected
modifiers are the same as those of its component type. For arrays of
primitives, this component type is represented by one of the primitive
classes (for example, java.lang.Integer.TYPE).
If the class is a primitive class, its public modifier is always true,
and its protected and private modifiers are always false.
If the class is an array class or a primitive class then its final
modifier is always true and its interface modifier is always false.
The values of its other modifiers are not determined by this specification.
For the class indicated by klass, return a count of
methods via method_count_ptr and a list of
method IDs via methods_ptr. The method list contains
constructors and static initializers as well as true methods.
Only directly declared methods are returned (not inherited methods).
An empty method list is returned for array classes and primitive classes
(for example, java.lang.Integer.TYPE).
On return, points to the method ID array.
Agent passes a pointer to a jmethodID*. On return, the jmethodID* points to a newly allocated array of size *method_count_ptr. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
For the class indicated by klass, return a count of fields
via field_count_ptr and a list of field IDs via
fields_ptr.
Only directly declared fields are returned (not inherited fields).
Fields are returned in the order they occur in the class file.
An empty field list is returned for array classes and primitive classes
(for example, java.lang.Integer.TYPE).
Use JNI to determine the length of an array.
On return, points to the field ID array.
Agent passes a pointer to a jfieldID*. On return, the jfieldID* points to a newly allocated array of size *field_count_ptr. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Return the direct super-interfaces of this class. For a class, this
function returns the interfaces declared in its implements
clause. For an interface, this function returns the interfaces declared in
its extends clause.
An empty interface list is returned for array classes and primitive classes
(for example, java.lang.Integer.TYPE).
On return, points to the interface array.
Agent passes a pointer to a jclass*. On return, the jclass* points to a newly allocated array of size *interface_count_ptr. The array should be freed with Deallocate. The objects returned by interfaces_ptr are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
On return, points to the value of the
minor_version item of the
Class File Format.
Note: to be consistent with the Class File Format,
the minor version number is the first parameter.
Agent passes a pointer to a jint. On return, the jint has been set.
For the class indicated by klass,
return the raw bytes of the constant pool in the format of the
constant_pool item of the
in the .
The format of the constant pool may differ between versions
of the Class File Format, so, the
minor and major
class version numbers should be checked for
compatibility.
The returned constant pool might not have the same layout or
contents as the constant pool in the defining class file.
The constant pool returned by GetConstantPool() may have
more or fewer entries than the defining constant pool.
Entries may be in a different order.
The constant pool returned by GetConstantPool() will match the
constant pool used by
GetBytecodes().
That is, the bytecodes returned by GetBytecodes() will have
constant pool indices which refer to constant pool entries returned
by GetConstantPool().
Note that since RetransformClasses
and RedefineClasses can change
the constant pool, the constant pool returned by this function
can change accordingly. Thus, the correspondence between
GetConstantPool() and GetBytecodes() does not hold if there
is an intervening class retransformation or redefinition.
The value of a constant pool entry used by a given bytecode will
match that of the defining class file (even if the indices don't match).
Constant pool entries which are not used directly or indirectly by
bytecodes (for example, UTF-8 strings associated with annotations) are
not required to exist in the returned constant pool.
may
only be called during the start or the live
phase
No
146
1.1
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the number of entries
in the constant pool table plus one.
This corresponds to the constant_pool_count
item of the Class File Format.
Agent passes a pointer to a jint. On return, the jint has been set.
On return, points to the number of bytes
in the returned raw constant pool.
Agent passes a pointer to a jint. On return, the jint has been set.
constant_pool_bytes_ptr
unsigned char**
On return, points to the raw constant pool, that is the bytes
defined by the constant_pool item of the
Class File Format
Agent passes a pointer to a unsigned char*. On return, the unsigned char* points to a newly allocated array of size *constant_pool_byte_count_ptr. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Determines whether a class object reference represents an interface.
The jboolean result is
JNI_TRUE if the "class" is actually an interface,
JNI_FALSE otherwise.
Determines whether a class is modifiable.
If a class is modifiable (is_modifiable_class_ptr
returns JNI_TRUE) the class can be
redefined with RedefineClasses (assuming
the agent possesses the
can_redefine_classes
capability) or
retransformed with RetransformClasses (assuming
the agent possesses the
can_retransform_classes
capability).
If a class is not modifiable (is_modifiable_class_ptr
returns JNI_FALSE) the class can be neither
redefined nor retransformed.
Primitive classes (for example, java.lang.Integer.TYPE)
and array classes are never modifiable.
On return, points to the class loader that loaded
this class.
If the class was not created by a class loader
or if the class loader is the bootstrap class loader,
points to NULL.
Agent passes a pointer to a jobject. On return, the jobject has been set. The object returned by classloader_ptr is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
For the class indicated by klass, return the debug
extension via source_debug_extension_ptr.
The returned string
contains exactly the debug extension information present in the
class file of klass.
may
only be called during the start or the live
phase
No
90
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the class's debug extension, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
This function facilitates the
bytecode instrumentation
of already loaded classes.
To replace the class definition without reference to the existing
bytecodes, as one might do when recompiling from source for
fix-and-continue debugging, RedefineClasses
function should be used instead.
When classes are initially loaded or when they are
redefined,
the initial class file bytes can be transformed with the
ClassFileLoadHook event.
This function reruns the transformation process
(whether or not a transformation has previously occurred).
This retransformation follows these steps:
starting from the initial class file bytes
for each retransformation
incapable
agent which received a
ClassFileLoadHook event during the previous
load or redefine, the bytes it returned
(via the new_class_data parameter)
are reused as the output of the transformation;
note that this is equivalent to reapplying
the previous transformation, unaltered. except that
the ClassFileLoadHook event
is not sent to these agents
for each retransformation
capable
agent, the ClassFileLoadHook event is sent,
allowing a new transformation to be applied
the transformed class file bytes are installed as the new
definition of the class
See the ClassFileLoadHook event for more details.
The initial class file bytes represent the bytes passed to
ClassLoader.defineClass
or RedefineClasses (before any transformations
were applied), however they may not exactly match them.
The constant pool may differ in ways described in
GetConstantPool.
Constant pool indices in the bytecodes of methods will correspond.
Some attributes may not be present.
Where order is not meaningful, for example the order of methods,
order may not be preserved.
Retransformation can cause new versions of methods to be installed.
Old method versions may become
obsolete
The new method version will be used on new invokes.
If a method has active stack frames, those active frames continue to
run the bytecodes of the original method version.
This function does not cause any initialization except that which
would occur under the customary JVM semantics.
In other words, retransforming a class does not cause its initializers to be
run. The values of static fields will remain as they were
prior to the call.
Threads need not be suspended.
All breakpoints in the class are cleared.
All attributes are updated.
Instances of the retransformed class are not affected -- fields retain their
previous values.
Tags on the instances are
also unaffected.
In response to this call, no events other than the
ClassFileLoadHook event
will be sent.
The retransformation may change method bodies, the constant pool and attributes.
The retransformation must not add, remove or rename fields or methods, change the
signatures of methods, change modifiers, or change inheritance.
These restrictions may be lifted in future versions.
See the error return description below for information on error codes
returned if an unsupported retransformation is attempted.
The class file bytes are not verified or installed until they have passed
through the chain of ClassFileLoadHook events, thus the
returned error code reflects the result of the transformations.
If any error code is returned other than JVMTI_ERROR_NONE,
none of the classes to be retransformed will have a new definition installed.
When this function returns (with the error code of JVMTI_ERROR_NONE)
all of the classes to be retransformed will have their new definitions installed.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Can retransform classes with RetransformClasses.
In addition to the restrictions imposed by the specific
implementation on this capability (see the
Capability section),
this capability must be set before the
ClassFileLoadHook event is enabled for the
first time in this environment.
An environment that possesses this capability at the time that
ClassFileLoadHook is enabled for the first time is
said to be retransformation capable.
An environment that does not possess this capability at the time that
ClassFileLoadHook is enabled for the first time is
said to be retransformation incapable.
All classes given are redefined according to the definitions
supplied.
This function is used to replace the definition of a class
with a new definition, as might be needed in fix-and-continue
debugging.
Where the existing class file bytes are to be transformed, for
example in
bytecode instrumentation,
RetransformClasses should be used.
Redefinition can cause new versions of methods to be installed.
Old method versions may become
obsolete
The new method version will be used on new invokes.
If a method has active stack frames, those active frames continue to
run the bytecodes of the original method version.
If resetting of stack frames is desired, use
PopFrame
to pop frames with obsolete method versions.
This function does not cause any initialization except that which
would occur under the customary JVM semantics.
In other words, redefining a class does not cause its initializers to be
run. The values of static fields will remain as they were
prior to the call.
Threads need not be suspended.
All breakpoints in the class are cleared.
All attributes are updated.
Instances of the redefined class are not affected -- fields retain their
previous values.
Tags on the instances are
also unaffected.
In response to this call, the JVM TI event
Class File Load Hook
will be sent (if enabled), but no other JVM TI events will be sent.
The redefinition may change method bodies, the constant pool and attributes.
The redefinition must not add, remove or rename fields or methods, change the
signatures of methods, change modifiers, or change inheritance.
These restrictions may be lifted in future versions.
See the error return description below for information on error codes
returned if an unsupported redefinition is attempted.
The class file bytes are not verified or installed until they have passed
through the chain of ClassFileLoadHook events, thus the
returned error code reflects the result of the transformations applied
to the bytes passed into class_definitions.
If any error code is returned other than JVMTI_ERROR_NONE,
none of the classes to be redefined will have a new definition installed.
When this function returns (with the error code of JVMTI_ERROR_NONE)
all of the classes to be redefined will have their new definitions installed.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
For the object indicated by object,
return via size_ptr the size of the object.
This size is an implementation-specific approximation of
the amount of storage consumed by this object.
It may include some or all of the object's overhead, and thus
is useful for comparison within an implementation but not
between implementations.
The estimate may change during a single invocation of the JVM.
For the object indicated by object,
return via hash_code_ptr a hash code.
This hash code could be used to maintain a hash table of object references,
however, on some implementations this can cause significant performance
impacts--in most cases
tags
will be a more efficient means of associating information with objects.
This function guarantees
the same hash code value for a particular object throughout its life
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, filled with monitor information for the
specified object.
Agent passes a pointer to a jvmtiMonitorUsage. On return, the jvmtiMonitorUsage has been set. The object returned in the field owner of jvmtiMonitorUsage is a JNI local reference and must be managed.
The pointer returned in the field waiters of jvmtiMonitorUsage is a newly allocated array. The array should be freed with Deallocate. The objects returned in the field waiters of jvmtiMonitorUsage are JNI local references and must be managed.
The pointer returned in the field notify_waiters of jvmtiMonitorUsage is a newly allocated array. The array should be freed with Deallocate. The objects returned in the field notify_waiters of jvmtiMonitorUsage are JNI local references and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
For the field indicated by klass and field,
return the field name via name_ptr and field signature via
signature_ptr.
Field signatures are defined in the JNI Specification and
are referred to as
in the .
On return, points to the field name, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
name_ptr
is
NULL, the name is not returned.
signature_ptr
char
**
On return, points to the field signature, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
signature_ptr
is
NULL, the signature is not returned.
generic_ptr
char
**
On return, points to the generic signature of the field, encoded as a
modified UTF-8 string.
If there is no generic signature attribute for the field, then,
on return, points to NULL.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
generic_ptr
is
NULL, the generic signature is not returned.
Errors
This function returns either a
universal error
or one of the following errors
For the field indicated by klass and field
return the class that defined it via declaring_class_ptr.
The declaring class will either be klass, a superclass, or
an implemented interface.
On return, points to the declaring class
Agent passes a pointer to a jclass. On return, the jclass has been set. The object returned by declaring_class_ptr is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
For the field indicated by klass and field, return a
value indicating whether the field is synthetic via is_synthetic_ptr.
Synthetic fields are generated by the compiler but not present in the
original source code.
may
only be called during the start or the live
phase
No
63
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
These functions provide information about a method (represented as a
jmethodID) and set how methods are processed.
Obsolete Methods
The functions RetransformClasses and
RedefineClasses can cause new versions
of methods to be installed.
An original version of a method is considered equivalent
to the new version if:
their bytecodes are the same except for indices into the
constant pool and
the referenced constants are equal.
An original method version which is not equivalent to the
new method version is called obsolete and is assigned a new method ID;
the original method ID now refers to the new method version.
A method ID can be tested for obsolescence with
IsMethodObsolete.
For the method indicated by method,
return the method name via name_ptr and method signature via
signature_ptr.
Method signatures are defined in the JNI Specification and are referred to as
in the .
Note this is different
than method signatures as defined in the Java Language Specification.
On return, points to the method name, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
name_ptr
is
NULL, the name is not returned.
signature_ptr
char
**
On return, points to the method signature, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
signature_ptr
is
NULL, the signature is not returned.
generic_ptr
char
**
On return, points to the generic signature of the method, encoded as a
modified UTF-8 string.
If there is no generic signature attribute for the method, then,
on return, points to NULL.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
If
generic_ptr
is
NULL, the generic signature is not returned.
Errors
This function returns either a
universal error
or one of the following errors
On return, points to the declaring class
Agent passes a pointer to a jclass. On return, the jclass has been set. The object returned by declaring_class_ptr is a JNI local reference and must be managed.
Errors
This function returns either a
universal error
or one of the following errors
For the method indicated by method,
return the number of local variable slots used by the method,
including the local variables used to pass parameters to the
method on its invocation.
See max_locals in the
of the .
For the method indicated by method,
return via max_ptr the number of local variable slots used
by the method's arguments.
Note that two-word arguments use two slots.
For the method indicated by method,
return a table of source line number entries. The size of the table is
returned via entry_count_ptr and the table itself is
returned via table_ptr.
may
only be called during the start or the live
phase
No
70
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the line number table pointer.
Agent passes a pointer to a jvmtiLineNumberEntry*. On return, the jvmtiLineNumberEntry* points to a newly allocated array of size *entry_count_ptr. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
For the method indicated by method,
return the beginning and ending addresses through
start_location_ptr and end_location_ptr. In a
conventional byte code indexing scheme,
start_location_ptr will always point to zero
and end_location_ptr
will always point to the byte code count minus one.
On return, points to the first location, or
-1 if location information is not available.
If the information is available and
GetJLocationFormat
returns JVMTI_JLOCATION_JVMBCI
then this will always be zero.
Agent passes a pointer to a jlocation. On return, the jlocation has been set.
On return, points to the last location,
or -1 if location information is not available.
Agent passes a pointer to a jlocation. On return, the jlocation has been set.
Errors
This function returns either a
universal error
or one of the following errors
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
The length of the valid section for this local variable.
The last code array index where the local variable is valid
is start_location + length.
name
char*
The local variable name, encoded as a
modified UTF-8 string.
signature
char*
The local variable's type signature, encoded as a
modified UTF-8 string.
The signature format is the same as that defined in
of the
generic_signature
char*
The local variable's generic signature, encoded as a
modified UTF-8 string.
The value of this field will be NULL for any local
variable which does not have a generic type.
On return, points to an array of local variable table entries.
Agent passes a pointer to a jvmtiLocalVariableEntry*. On return, the jvmtiLocalVariableEntry* points to a newly allocated array of size *entry_count_ptr. The array should be freed with Deallocate. The pointers returned in the field name of jvmtiLocalVariableEntry are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field signature of jvmtiLocalVariableEntry are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field generic_signature of jvmtiLocalVariableEntry are newly allocated arrays. The arrays should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
For the method indicated by method,
return the byte codes that implement the method. The number of
bytecodes is returned via bytecode_count_ptr. The byte codes
themselves are returned via bytecodes_ptr.
may
only be called during the start or the live
phase
No
75
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, points to the length of the byte code array
Agent passes a pointer to a jint. On return, the jint has been set.
bytecodes_ptr
unsigned char**
On return, points to the pointer to the byte code array
Agent passes a pointer to a unsigned char*. On return, the unsigned char* points to a newly allocated array of size *bytecode_count_ptr. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
For the method indicated by method, return a
value indicating whether the method is synthetic via is_synthetic_ptr.
Synthetic methods are generated by the compiler but not present in the
original source code.
may
only be called during the start or the live
phase
No
77
1.0
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
This function modifies the failure handling of
native method resolution by allowing retry
with a prefix applied to the name.
When used with the
ClassFileLoadHook
event, it enables native methods to be
instrumented.
Since native methods cannot be directly instrumented
(they have no bytecodes), they must be wrapped with
a non-native method which can be instrumented.
For example, if we had:
native boolean foo(int x);
We could transform the class file (with the
ClassFileLoadHook event) so that this becomes:
boolean foo(int x) {
... record entry to foo ...
return wrapped_foo(x);
}
native boolean wrapped_foo(int x);
Where foo becomes a wrapper for the actual native method
with the appended prefix "wrapped_". Note that
"wrapped_" would be a poor choice of prefix since it
might conceivably form the name of an existing method
thus something like "$$$MyAgentWrapped$$$_" would be
better but would make these examples less readable.
The wrapper will allow data to be collected on the native
method call, but now the problem becomes linking up the
wrapped method with the native implementation.
That is, the method wrapped_foo needs to be
resolved to the native implementation of foo,
which might be:
This function allows the prefix to be specified and the
proper resolution to occur.
Specifically, when the standard resolution fails, the
resolution is retried taking the prefix into consideration.
There are two ways that resolution occurs, explicit
resolution with the JNI function RegisterNatives
and the normal automatic resolution. For
RegisterNatives, the VM will attempt this
association:
method(foo) -> nativeImplementation(foo)
When this fails, the resolution will be retried with
the specified prefix prepended to the method name,
yielding the correct resolution:
When this fails, the resolution will be retried with
the specified prefix deleted from the implementation name,
yielding the correct resolution:
method(wrapped_foo) -> nativeImplementation(foo)
Note that since the prefix is only used when standard
resolution fails, native methods can be wrapped selectively.
Since each JVM TI environment is independent and
can do its own transformation of the bytecodes, more
than one layer of wrappers may be applied. Thus each
environment needs its own prefix. Since transformations
are applied in order, the prefixes, if applied, will
be applied in the same order.
The order of transformation application is described in
the ClassFileLoadHook event.
Thus if three environments applied
wrappers, foo might become
$env3_$env2_$env1_foo. But if, say,
the second environment did not apply a wrapper to
foo it would be just
$env3_$env1_foo. To be able to
efficiently determine the sequence of prefixes,
an intermediate prefix is only applied if its non-native
wrapper exists. Thus, in the last example, even though
$env1_foo is not a native method, the
$env1_ prefix is applied since
$env1_foo exists.
Since the prefixes are used at resolution time
and since resolution may be arbitrarily delayed, a
native method prefix must remain set as long as there
are corresponding prefixed native methods.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
The prefix to apply, encoded as a
modified UTF-8 string.
Agent passes in an array of char.
If
prefix
is
NULL,
any existing prefix in this environment is cancelled
.
Errors
This function returns either a
universal error
or one of the following errors
For a normal agent, SetNativeMethodPrefix
will provide all needed native method prefixing.
For a meta-agent that performs multiple independent class
file transformations (for example as a proxy for another
layer of agents) this function allows each transformation
to have its own prefix.
The prefixes are applied in the order supplied and are
processed in the same manor as described for the
application of prefixes from multiple JVM TI environments
in SetNativeMethodPrefix.
Any previous prefixes are replaced. Thus, calling this
function with a prefix_count of 0
disables prefixing in this environment.
SetNativeMethodPrefix and this function
are the two ways to set the prefixes.
Calling SetNativeMethodPrefix with
a prefix is the same as calling this function with
prefix_count of 1.
Calling SetNativeMethodPrefix with
NULL is the same as calling this function with
prefix_count of 0.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Destroy the raw monitor.
If the monitor being destroyed has been entered by this thread, it will be
exited before it is destroyed.
If the monitor being destroyed has been entered by another thread,
an error will be returned and the monitor will not be destroyed.
Gain exclusive ownership of a raw monitor.
The same thread may enter a monitor more then once.
The thread must
exit
the monitor the same number of times as it is entered.
If a monitor is entered during OnLoad (before attached threads exist)
and has not exited when attached threads come into existence, the enter
is considered to have occurred on the main thread.
Wait for notification of the raw monitor.
Causes the current thread to wait until either another thread calls
RawMonitorNotify or
RawMonitorNotifyAll
for the specified raw monitor, or the specified
timeout
has elapsed.
Provides the ability to intercept and resend
Java Native Interface (JNI) function calls
by manipulating the JNI function table.
See in the Java Native Interface Specification.
The following example illustrates intercepting the
NewGlobalRef JNI call in order to count reference
creation.
Sometime after myInit is called the user's JNI
code is executed which makes the call to create a new global
reference. Instead of going to the normal JNI implementation
the call goes to myNewGlobalRef. Note that a
copy of the original function table is kept so that the normal
JNI function can be called after the data is collected.
Note also that any JNI functions which are not overwritten
will behave normally.
Set the JNI function table
in all current and future JNI environments.
As a result, all future JNI calls are directed to the specified functions.
Use GetJNIFunctionTable to get the
function table to pass to this function.
For this function to take effect the the updated table entries must be
used by the JNI clients.
Since the table is defined const some compilers may optimize
away the access to the table, thus preventing this function from taking
effect.
The table is copied--changes to the local copy of the
table have no effect.
This function affects only the function table, all other aspects of the environment are
unaffected.
See the examples above.
Get the JNI function table.
The JNI function table is copied into allocated memory.
If SetJNIFunctionTable
has been called, the modified (not the original) function
table is returned.
Only the function table is copied, no other aspects of the environment
are copied.
See the examples above.
On return, *function_table
points a newly allocated copy of the JNI function table.
Agent passes a pointer to a jniNativeInterface*. On return, the jniNativeInterface* points to a newly allocated array. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Set the functions to be called for each event.
The callbacks are specified by supplying a replacement function table.
The function table is copied--changes to the local copy of the
table have no effect.
This is an atomic action, all callbacks are set at once.
No events are sent before this function is called.
When an entry is NULL or when the event is beyond
size_of_callbacks no event is sent.
Details on events are
described later in this document.
An event must be enabled and have a callback in order to be
sent--the order in which this function and
SetEventNotificationMode
are called does not affect the result.
If mode is JVMTI_ENABLE,
the event event_type will be enabled
JVMTI_DISABLE
0
If mode is JVMTI_DISABLE,
the event event_type will be disabled
If thread is NULL,
the event is enabled or disabled globally; otherwise, it is
enabled or disabled for a particular thread.
An event is generated for
a particular thread if it is enabled either at the thread or global
levels.
See below for information on specific events.
The following events cannot be controlled at the thread
level through this function.
Initially, no events are enabled at either the thread level
or the global level.
Any needed capabilities (see Event Enabling Capabilities below) must be possessed
before calling this function.
Details on events are
described below.
Generate events to represent the current state of the VM.
For example, if event_type is
JVMTI_EVENT_COMPILED_METHOD_LOAD,
a CompiledMethodLoad event will be
sent for each currently compiled method.
Methods that were loaded and now have been unloaded are not sent.
The history of what events have previously been sent does not
effect what events are sent by this function--for example,
all currently compiled methods
will be sent each time this function is called.
This function is useful when
events may have been missed due to the agent attaching after program
execution begins; this function generates the missed events.
Attempts to execute Java programming language code or
JNI functions may be paused until this function returns -
so neither should be called from the thread sending the event.
This function returns only after the missed events have been
sent, processed and have returned.
The event may be sent on a different thread than the thread
on which the event occurred.
The callback for the event must be set with
SetEventCallbacks
and the event must be enabled with
SetEventNotificationMode
or the events will not occur.
If the VM no longer has the information to generate some or
all of the requested events, the events are simply not sent -
no error is returned.
Only the following events are supported:
These functions
allow a JVM TI implementation to provide functions and events
beyond those defined in this specification.
Both extension functions and extension events have parameters
each of which has a 'type' and 'kind' chosen from the following tables:
Java programming language primitive type - byte.
JNI type jbyte.
JVMTI_TYPE_JCHAR
102
Java programming language primitive type - char.
JNI type jchar.
JVMTI_TYPE_JSHORT
103
Java programming language primitive type - short.
JNI type jshort.
JVMTI_TYPE_JINT
104
Java programming language primitive type - int.
JNI type jint.
JVMTI_TYPE_JLONG
105
Java programming language primitive type - long.
JNI type jlong.
JVMTI_TYPE_JFLOAT
106
Java programming language primitive type - float.
JNI type jfloat.
JVMTI_TYPE_JDOUBLE
107
Java programming language primitive type - double.
JNI type jdouble.
JVMTI_TYPE_JBOOLEAN
108
Java programming language primitive type - boolean.
JNI type jboolean.
JVMTI_TYPE_JOBJECT
109
Java programming language object type - java.lang.Object.
JNI type jobject.
Returned values are JNI local references and must be managed.
JVMTI_TYPE_JTHREAD
110
Java programming language object type - java.lang.Thread.
JVM TI type jthread.
Returned values are JNI local references and must be managed.
JVMTI_TYPE_JCLASS
111
Java programming language object type - java.lang.Class.
JNI type jclass.
Returned values are JNI local references and must be managed.
JVMTI_TYPE_JVALUE
112
Union of all Java programming language primitive and object types -
JNI type jvalue.
Returned values which represent object types are JNI local references and must be managed.
JVMTI_TYPE_JFIELDID
113
Java programming language field identifier -
JNI type jfieldID.
JVMTI_TYPE_JMETHODID
114
Java programming language method identifier -
JNI type jmethodID.
JVMTI_TYPE_CCHAR
115
C programming language type - char.
JVMTI_TYPE_CVOID
116
C programming language type - void.
JVMTI_TYPE_JNIENV
117
JNI environment - JNIEnv.
Should be used with the correct jvmtiParamKind to make it a pointer type.
Returns an array of extension function info, one per function
Agent passes a pointer to a jvmtiExtensionFunctionInfo*. On return, the jvmtiExtensionFunctionInfo* points to a newly allocated array of size *extension_count_ptr. The array should be freed with Deallocate. The pointers returned in the field id of jvmtiExtensionFunctionInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field short_description of jvmtiExtensionFunctionInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field params of jvmtiExtensionFunctionInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field name of jvmtiParamInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field errors of jvmtiExtensionFunctionInfo are newly allocated arrays. The arrays should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Returns an array of extension event info, one per event
Agent passes a pointer to a jvmtiExtensionEventInfo*. On return, the jvmtiExtensionEventInfo* points to a newly allocated array of size *extension_count_ptr. The array should be freed with Deallocate. The pointers returned in the field id of jvmtiExtensionEventInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field short_description of jvmtiExtensionEventInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field params of jvmtiExtensionEventInfo are newly allocated arrays. The arrays should be freed with Deallocate. The pointers returned in the field name of jvmtiParamInfo are newly allocated arrays. The arrays should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
This is the implementation-specific event.
The event handler is set with
SetExtensionEventCallback.
Event handlers for extension events must be declared varargs to match this definition.
Failure to do so could result in calling convention mismatch and undefined behavior
on some platforms.
For example, if the jvmtiParamInfo
returned by GetExtensionEvents indicates that
there is a jint parameter, the event handler should be
declared:
Sets the callback function for an extension event and
enables the event. Or, if the callback is NULL, disables
the event. Note that unlike standard events, setting
the callback and enabling the event are a single operation.
The capabilities functions allow you to change the
functionality available to JVM TI--that is,
which JVM TI
functions can be called, what events can be generated,
and what functionality these events and functions can
provide.
The "Capabilities" section of each function and event describe which
capabilities, if any, they are associated with. "Required Functionality"
means it is available for use and no capabilities must be added to use it.
"Optional Functionality" means the agent must possess the capability
before it can be used.
To possess a capability, the agent must
add the capability.
"Optional Features" describe capabilities which,
if added, extend the feature set.
The potentially available capabilities of each JVM TI implementation are different.
Depending on the implementation, a capability:
may never be added
may be added in either the OnLoad or live phase in any environment
may be added only during the OnLoad phase
may be possessed by only one environment at a time
may be possessed by only one environment at a time,
and only during the OnLoad phase
and so on ...
Frequently, the addition of a capability may incur a cost in execution speed, start up
time, and/or memory footprint. Note that the overhead of using a capability
is completely different than the overhead of possessing a capability.
Take single stepping as an example. When single stepping is on (that
is, when the event is enabled and thus actively sending events)
the overhead of sending and processing an event
on each instruction is huge in any implementation.
However, the overhead of possessing the capability may be small or large,
depending on the implementation. Also, when and if a capability is potentially
available depends on the implementation. Some examples:
One VM might perform all execution by compiling bytecodes into
native code and be unable to generate single step instructions.
In this implementation the capability can not be added.
Another VM may be able to switch execution to a single stepping
interpreter at any time. In this implementation, having the capability has no
overhead and could be added at any time.
Yet another VM might be able to choose a bytecode compiling or single stepping capable interpreted
execution engine at start up, but be unable to switch between them.
In this implementation the capability would need to be added
during the OnLoad phase (before bytecode
execution begins) and would have a large impact on execution speed
even if single stepping was never used.
Still another VM might be able to add an "is single stepping on" check
into compiled bytecodes or a generated interpreter. Again in this implementation
the capability would need to be added during the OnLoad phase but the overhead (a test
and branch on each instruction) would be considerably less.
For example, a freshly started agent (in the OnLoad function)
wants to enable all possible capabilities.
Note that, in general, this is not advisable as the agent may suffer
a performance penalty for functionality it is not using.
The code might look like this in C:
For example, if an agent wants to check if it can get
the bytecodes of a method (that is, it wants to check
if it previously added this capability and has not
relinquished it), the code might
look like this in C:
jvmtiCapabilities capa;
jvmtiError err;
err = (*jvmti)->GetCapabilities(jvmti, &capa);
if (err == JVMTI_ERROR_NONE) {
if (capa.can_get_bytecodes) { ... } }
The Capabilities Structure
The functions in this category use this capabilities structure
which contains boolean flags corresponding to each capability:
typedef struct {
unsigned int can_tag_objects : 1;
unsigned int can_generate_field_modification_events : 1;
unsigned int can_generate_field_access_events : 1;
unsigned int can_get_bytecodes : 1;
unsigned int can_get_synthetic_attribute : 1;
unsigned int can_get_owned_monitor_info : 1;
unsigned int can_get_current_contended_monitor : 1;
unsigned int can_get_monitor_info : 1;
unsigned int can_pop_frame : 1;
unsigned int can_redefine_classes : 1;
unsigned int can_signal_thread : 1;
unsigned int can_get_source_file_name : 1;
unsigned int can_get_line_numbers : 1;
unsigned int can_get_source_debug_extension : 1;
unsigned int can_access_local_variables : 1;
unsigned int can_maintain_original_method_order : 1;
unsigned int can_generate_single_step_events : 1;
unsigned int can_generate_exception_events : 1;
unsigned int can_generate_frame_pop_events : 1;
unsigned int can_generate_breakpoint_events : 1;
unsigned int can_suspend : 1;
unsigned int can_redefine_any_class : 1;
unsigned int can_get_current_thread_cpu_time : 1;
unsigned int can_get_thread_cpu_time : 1;
unsigned int can_generate_method_entry_events : 1;
unsigned int can_generate_method_exit_events : 1;
unsigned int can_generate_all_class_hook_events : 1;
unsigned int can_generate_compiled_method_load_events : 1;
unsigned int can_generate_monitor_events : 1;
unsigned int can_generate_vm_object_alloc_events : 1;
unsigned int can_generate_native_method_bind_events : 1;
unsigned int can_generate_garbage_collection_events : 1;
unsigned int can_generate_object_free_events : 1;
unsigned int can_force_early_return : 1;
unsigned int can_get_owned_monitor_stack_depth_info : 1;
unsigned int can_get_constant_pool : 1;
unsigned int can_set_native_method_prefix : 1;
unsigned int can_retransform_classes : 1;
unsigned int can_retransform_any_class : 1;
unsigned int can_generate_resource_exhaustion_heap_events : 1;
unsigned int can_generate_resource_exhaustion_threads_events : 1;
unsigned int : 7;
unsigned int : 16;
unsigned int : 16;
unsigned int : 16;
unsigned int : 16;
unsigned int : 16;
} jvmtiCapabilities;
Can retransform classes with RetransformClasses.
In addition to the restrictions imposed by the specific
implementation on this capability (see the
Capability section),
this capability must be set before the
ClassFileLoadHook event is enabled for the
first time in this environment.
An environment that possesses this capability at the time that
ClassFileLoadHook is enabled for the first time is
said to be retransformation capable.
An environment that does not possess this capability at the time that
ClassFileLoadHook is enabled for the first time is
said to be retransformation incapable.
Returns via capabilities_ptr the JVM TI
features that can potentially be possessed by this environment
at this time.
The returned capabilities differ from the complete set of capabilities
implemented by the VM in two cases: another environment possesses
capabilities that can only be possessed by one environment, or the
current phase is live,
and certain capabilities can only be added during the OnLoad phase.
The AddCapabilities function
may be used to set any or all or these capabilities.
Currently possessed capabilities are included.
Typically this function is used in the OnLoad function.
Some virtual machines may allow a limited set of capabilities to be
added in the live phase.
In this case, the set of potentially available capabilities
will likely differ from the OnLoad phase set.
See the
Capability Examples.
On return, points to the JVM TI capabilities that may be added.
Agent passes a pointer to a jvmtiCapabilities. On return, the jvmtiCapabilities has been set.
Errors
This function returns either a
universal error
or one of the following errors
Set new capabilities by adding the capabilities
whose values are set to one (1) in
*capabilities_ptr.
All previous capabilities are retained.
Typically this function is used in the OnLoad function.
Some virtual machines may allow a limited set of capabilities to be
added in the live phase.
See the
Capability Examples.
Relinquish the capabilities
whose values are set to one (1) in
*capabilities_ptr.
Some implementations may allow only one environment to have a capability
(see the capability introduction).
This function releases capabilities
so that they may be used by other agents.
All other capabilities are retained.
The capability will no longer be present in GetCapabilities.
Attempting to relinquish a capability that the agent does not possess is not an error.
Returns via capabilities_ptr the optional JVM TI
features which this environment currently possesses.
Each possessed capability is indicated by a one (1) in the
corresponding field of the capabilities
structure.
An environment does not possess a capability unless it has been successfully added with
AddCapabilities.
An environment only loses possession of a capability if it has been relinquished with
RelinquishCapabilities. Thus, this function returns the net result
of the AddCapabilities and RelinquishCapabilities calls which
have been made.
See the
Capability Examples.
These functions provide timing information.
The resolution at which the time is updated is not specified.
They provides nanosecond precision, but not necessarily nanosecond accuracy.
Details about the timers, such as their maximum values, can be accessed with
the timer information functions.
Timer Info
The information function for each timer returns this data structure.
The maximum value the timer can reach.
After this value is reached the timer wraps back to zero.
This is an unsigned value. If tested or printed as a jlong (signed value)
it may appear to be a negative number.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, filled with information describing the time
returned by GetCurrentThreadCpuTime.
Agent passes a pointer to a jvmtiTimerInfo. On return, the jvmtiTimerInfo has been set.
Errors
This function returns either a
universal error
or one of the following errors
Return the CPU time utilized by the current thread.
Note that the GetThreadCpuTime
function provides CPU time for any thread, including
the current thread. GetCurrentThreadCpuTime
exists to support platforms which cannot
supply CPU time for threads other than the current
thread or which have more accurate information for
the current thread (see
GetCurrentThreadCpuTimerInfo vs
GetThreadCpuTimerInfo).
On many platforms this call will be equivalent to:
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Can get current thread CPU time.
If this capability is enabled after threads have started,
the implementation may choose any time up
to and including the time that the capability is enabled
as the point where CPU time collection starts.
This capability must be potentially available on any
platform where
can_get_thread_cpu_time
is potentially available.
On return, points to the CPU time used by this thread
in nanoseconds.
This is an unsigned value. If tested or printed as a jlong (signed value)
it may appear to be a negative number.
Agent passes a pointer to a jlong. On return, the jlong has been set.
Errors
This function returns either a
universal error
or one of the following errors
Get information about the
GetThreadCpuTime timer.
The fields of the jvmtiTimerInfo structure
are filled in with details about the timer.
This information is specific to the platform and the implementation of
GetThreadCpuTime and thus
does not vary by thread nor does it vary
during a particular invocation of the VM.
Note that the implementations of GetCurrentThreadCpuTime
and GetThreadCpuTime may differ, and thus the values
returned by GetCurrentThreadCpuTimerInfo
and GetThreadCpuTimerInfo
may differ -- see GetCurrentThreadCpuTime for more information.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
On return, filled with information describing the time
returned by GetThreadCpuTime.
Agent passes a pointer to a jvmtiTimerInfo. On return, the jvmtiTimerInfo has been set.
Errors
This function returns either a
universal error
or one of the following errors
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
function.
Can get thread CPU time.
If this capability is enabled after threads have started,
the implementation may choose any time up
to and including the time that the capability is enabled
as the point where CPU time collection starts.
On return, points to the CPU time used by the specified thread
in nanoseconds.
This is an unsigned value. If tested or printed as a jlong (signed value)
it may appear to be a negative number.
Agent passes a pointer to a jlong. On return, the jlong has been set.
Errors
This function returns either a
universal error
or one of the following errors
Get information about the
GetTime timer.
The fields of the jvmtiTimerInfo structure
are filled in with details about the timer.
This information will not change during a particular invocation of the VM.
On return, filled with information describing the time
returned by GetTime.
Agent passes a pointer to a jvmtiTimerInfo. On return, the jvmtiTimerInfo has been set.
Errors
This function returns either a
universal error
or one of the following errors
Return the current value of the system timer, in nanoseconds.
The value returned represents nanoseconds since some fixed but
arbitrary time (perhaps in the future, so values may be
negative). This function provides nanosecond precision, but not
necessarily nanosecond accuracy. No guarantees are made about
how frequently values change.
Get information about this timer with
GetTimerInfo.
On return, points to the time in nanoseconds.
This is an unsigned value. If tested or printed as a jlong (signed value)
it may appear to be a negative number.
Agent passes a pointer to a jlong. On return, the jlong has been set.
Errors
This function returns either a
universal error
or one of the following errors
Returns the number of processors available to the Java virtual machine.
This value may change during a particular invocation of the virtual machine.
Applications that are sensitive to the number of available processors should
therefore occasionally poll this property.
On return, points to the maximum number of processors available to the
virtual machine; never smaller than one.
Agent passes a pointer to a jint. On return, the jint has been set.
Errors
This function returns either a
universal error
or one of the following errors
These functions allow the agent to add to the locations that a class loader searches for a class.
This is useful for installing instrumentation under the correct class loader.
This function can be used to cause instrumentation classes to be defined by the
bootstrap class loader. See
in the .
After the bootstrap
class loader unsuccessfully searches for a class, the specified platform-dependent
search path segment will be searched as well. Only one segment may be specified in
the segment. This function may be called multiple times to add multiple segments,
the segments will be searched in the order that this function was called.
In the OnLoad phase the function may be used to specify any platform-dependent
search path segment to be searched after the bootstrap class loader unsuccessfully searches
for a class. The segment is typically a directory or JAR file.
In the live phase the segment may be used to specify any platform-dependent
path to a . The agent should take care that the JAR file does not
contain any classes or resources other than those to be defined by the bootstrap
class loader for the purposes of instrumentation.
The specifies that a subsequent attempt to resolve a symbolic
reference that the Java virtual machine has previously unsuccessfully attempted
to resolve always fails with the same error that was thrown as a result of the
initial resolution attempt. Consequently, if the JAR file contains an entry
that corresponds to a class for which the Java virtual machine has
unsuccessfully attempted to resolve a reference, then subsequent attempts to
resolve that reference will fail with the same error as the initial attempt.
This function can be used to cause instrumentation classes to be
defined by the system class loader. See
in the .
After the class loader unsuccessfully searches for a class, the specified platform-dependent search
path segment will be searched as well. Only one segment may be specified in the
segment. This function may be called multiple times to add multiple segments, the
segments will be searched in the order that this function was called.
In the OnLoad phase the function may be used to specify any platform-dependent
search path segment to be searched after the system class loader unsuccessfully searches
for a class. The segment is typically a directory or JAR file.
In the live phase the segment is a platform-dependent path to a to be
searched after the system class loader unsuccessfully searches for a class. The agent should
take care that the JAR file does not contain any classes or resources other than those to be
defined by the system class loader for the purposes of instrumentation.
In the live phase the system class loader supports adding a JAR file to be searched if
the system class loader implements a method name appendToClassPathForInstrumentation
which takes a single parameter of type java.lang.String. The method is not required
to have public access.
The specifies that a subsequent attempt to resolve a symbolic
reference that the Java virtual machine has previously unsuccessfully attempted
to resolve always fails with the same error that was thrown as a result of the
initial resolution attempt. Consequently, if the JAR file contains an entry
that corresponds to a class for which the Java virtual machine has
unsuccessfully attempted to resolve a reference, then subsequent attempts to
resolve that reference will fail with the same error as the initial attempt.
The list of VM system property keys which may be used with
GetSystemProperty is returned.
It is strongly recommended that virtual machines provide the
following property keys:
java.vm.vendor
java.vm.version
java.vm.name
java.vm.info
java.library.path
java.class.path
Provides access to system properties defined by and used
by the VM.
Properties set on the command-line are included.
This allows getting and setting of these properties
before the VM even begins executing bytecodes.
Since this is a VM view of system properties, the set of available
properties will usually be different than that
in java.lang.System.getProperties.
JNI method invocation may be used to access
java.lang.System.getProperties.
The set of properties may grow during execution.
On return, points to the number of property keys returned.
Agent passes a pointer to a jint. On return, the jint has been set.
property_ptr
char***
On return, points to an array of property keys, encoded as
modified UTF-8 strings.
Agent passes a pointer to a char**. On return, the char** points to a newly allocated array of size *count_ptr, each element of which is also newly allocated.
The array should be freed with Deallocate.
Each of the elements should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Return a VM system property value given the property key.
The function GetSystemProperties
returns the set of property keys which may be used.
The properties which can be retrieved may grow during
execution.
Since this is a VM view of system properties, the values
of properties may differ from that returned by
java.lang.System.getProperty(String).
A typical VM might copy the values of the VM system
properties into the Properties held by
java.lang.System during the initialization
of that class. Thereafter any changes to the VM system
properties (with SetSystemProperty)
or the java.lang.System system properties
(with java.lang.System.setProperty(String,String))
would cause the values to diverge.
JNI method invocation may be used to access
java.lang.System.getProperty(String).
may
only be called during the OnLoad or the live
phase
No
131
1.0
Capabilities
Required Functionality
Parameters
Name
Type
Description
property
const char*
The key of the property to retrieve, encoded as a
modified UTF-8 string.
Agent passes in an array of char.
value_ptr
char**
On return, points to the property value, encoded as a
modified UTF-8 string.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Set a VM system property value.
The function GetSystemProperties
returns the set of property keys, some of these may be settable.
See GetSystemProperty.
The key of the property, encoded as a
modified UTF-8 string.
Agent passes in an array of char.
value
const
char
*
The property value to set, encoded as a
modified UTF-8 string.
Agent passes in an array of char.
If
value
is
NULL,
do not set the value, but return JVMTI_ERROR_NOT_AVAILABLE
if the property is not writeable
.
Errors
This function returns either a
universal error
or one of the following errors
Primordial phase: between return from Agent_OnLoad and the
VMStart event.
JVMTI_PHASE_START
6
Start phase: when the VMStart event
is sent and until the VMInit event is sent.
JVMTI_PHASE_LIVE
4
Live phase: when the VMInit event is sent
and until the VMDeath event returns.
JVMTI_PHASE_DEAD
8
Dead phase: after the VMDeath event returns or after
start-up failure.
In the case of start-up failure the VM will proceed directly to the dead
phase skipping intermediate phases and neither a VMInit nor
VMDeath event will be sent.
Most JVM TI functions operate only in the live phase.
The following functions operate in either the OnLoad or live phases:
JNI functions (except the Invocation API) must only be used in the start or live phases.
Most JVM TI events are sent only in the live phase.
The following events operate in others phases:
Shutdown a JVM TI connection created with JNI GetEnv
(see JVM TI Environments).
Dispose of any resources held by the environment.
Threads suspended by this environment are not resumed by this call,
this must be done explicitly by the agent.
Memory allocated by this environment via calls to JVM TI functions
is not released, this can be done explicitly by the agent
by calling Deallocate.
Raw monitors created by this environment are not destroyed,
this can be done explicitly by the agent
by calling DestroyRawMonitor.
The state of threads waiting on raw monitors created by this environment
are not affected.
Any native method
prefixes for this environment will be unset;
the agent must remove any prefixed native methods before
dispose is called.
Any capabilities
held by this environment are relinquished.
Events enabled by this environment will no longer be sent, however
event handlers currently running will continue to run. Caution must
be exercised in the design of event handlers whose environment may
be disposed and thus become invalid during their execution.
This environment may not be used after this call.
This call returns to the caller.
The VM stores a pointer value associated with each environment.
This pointer value is called environment-local storage.
This value is NULL unless set with this function.
Agents can allocate memory in which they store environment specific
information. By setting environment-local storage it can then be
accessed with
GetEnvironmentLocalStorage.
Called by the agent to set the value of the JVM TI
environment-local storage. JVM TI supplies to the agent a pointer-size
environment-local storage that can be used to record per-environment
information.
Pointer through which the value of the environment local
storage is returned.
If environment-local storage has not been set with
SetEnvironmentLocalStorage returned
pointer is NULL.
Errors
This function returns either a
universal error
or one of the following errors
Return the JVM TI version via version_ptr.
The return value is the version identifier.
The version identifier includes major, minor and micro
version as well as the interface type.
Version Interface Types
Constant
Value
Description
JVMTI_VERSION_INTERFACE_JNI
0x00000000
Value of JVMTI_VERSION_MASK_INTERFACE_TYPE for JNI.
JVMTI_VERSION_INTERFACE_JVMTI
0x30000000
Value of JVMTI_VERSION_MASK_INTERFACE_TYPE for JVM TI.
Version Masks
Constant
Value
Description
JVMTI_VERSION_MASK_INTERFACE_TYPE
0x70000000
Mask to extract interface type.
The value of the version returned by this function masked with
JVMTI_VERSION_MASK_INTERFACE_TYPE is always
JVMTI_VERSION_INTERFACE_JVMTI
since this is a JVM TI function.
Return the symbolic name for an
error code.
For example
GetErrorName(env, JVMTI_ERROR_NONE, &err_name)
would return in err_name the string
"JVMTI_ERROR_NONE".
On return, points to the error name.
The name is encoded as a
modified UTF-8 string,
but is restricted to the ASCII subset.
Agent passes a pointer to a char*. On return, the char* points to a newly allocated array. The array should be freed with Deallocate.
Errors
This function returns either a
universal error
or one of the following errors
Although the greatest functionality is achieved with location information
referencing the virtual machine bytecode index, the definition of
jlocation has intentionally been left unconstrained to allow VM
implementations that do not have this information.
This function describes the representation of jlocation used in this VM.
If the returned format is JVMTI_JLOCATION_JVMBCI,
jlocations can
be used as in indices into the array returned by
GetBytecodes.
JLocation Format Enumeration (jvmtiJlocationFormat)
Constant
Value
Description
JVMTI_JLOCATION_JVMBCI
1
jlocation values represent virtual machine
bytecode indices--that is, offsets into the
virtual machine code for a method.
JVMTI_JLOCATION_MACHINEPC
2
jlocation values represent native machine
program counter values.
On return, points to the format identifier for jlocation values.
Agent passes a pointer to a jvmtiJlocationFormat. On return, the jvmtiJlocationFormat has been set.
Errors
This function returns either a
universal error
or one of the following errors
Every JVM TI function returns a jvmtiError error code.
It is the responsibility of the agent to call JVM TI functions with
valid parameters and in the proper context (calling thread is attached,
phase is correct, etc.).
Detecting some error conditions may be difficult, inefficient, or
impossible for an implementation.
The errors listed in
Function Specific Required Errors
must be detected by the implementation.
All other errors represent the recommended response to the error
condition.
Universal Errors
The following errors may be returned by any function
JVMTI_ERROR_NONE (0)
No error has occurred. This is the error code that is returned
on successful completion of the function.
JVMTI_ERROR_NULL_POINTER (100)
Pointer is unexpectedly NULL.
JVMTI_ERROR_OUT_OF_MEMORY (110)
The function attempted to allocate memory and no more memory was
available for allocation.
JVMTI_ERROR_ACCESS_DENIED (111)
The desired functionality has not been enabled in this virtual machine.
JVMTI_ERROR_UNATTACHED_THREAD (115)
The thread being used to call this function is not attached
to the virtual machine. Calls must be made from attached threads.
See AttachCurrentThread in the JNI invocation API.
JVMTI_ERROR_INVALID_ENVIRONMENT (116)
The JVM TI environment provided is no longer connected or is
not an environment.
JVMTI_ERROR_WRONG_PHASE (112)
The desired functionality is not available in the current
phase.
Always returned if the virtual machine has completed running.
JVMTI_ERROR_INTERNAL (113)
An unexpected internal error has occurred.
Function Specific Required Errors
The following errors are returned by some JVM TI functions and must
be returned by the implementation when the condition occurs.
JVMTI_ERROR_INVALID_PRIORITY (12)
Invalid priority.
JVMTI_ERROR_THREAD_NOT_SUSPENDED (13)
Thread was not suspended.
JVMTI_ERROR_THREAD_SUSPENDED (14)
Thread already suspended.
JVMTI_ERROR_THREAD_NOT_ALIVE (15)
This operation requires the thread to be alive--that is,
it must be started and not yet have died.
JVMTI_ERROR_CLASS_NOT_PREPARED (22)
The class has been loaded but not yet prepared.
JVMTI_ERROR_NO_MORE_FRAMES (31)
There are no Java programming language or JNI stack frames at the specified depth.
JVMTI_ERROR_OPAQUE_FRAME (32)
Information about the frame is not available (e.g. for native frames).
JVMTI_ERROR_DUPLICATE (40)
Item already set.
JVMTI_ERROR_NOT_FOUND (41)
Desired element (e.g. field or breakpoint) not found
JVMTI_ERROR_NOT_MONITOR_OWNER (51)
This thread doesn't own the raw monitor.
JVMTI_ERROR_INTERRUPT (52)
The call has been interrupted before completion.
JVMTI_ERROR_UNMODIFIABLE_CLASS (79)
The class cannot be modified.
JVMTI_ERROR_NOT_AVAILABLE (98)
The functionality is not available in this virtual machine.
JVMTI_ERROR_ABSENT_INFORMATION (101)
The requested information is not available.
JVMTI_ERROR_INVALID_EVENT_TYPE (102)
The specified event type ID is not recognized.
JVMTI_ERROR_NATIVE_METHOD (104)
The requested information is not available for native method.
JVMTI_ERROR_CLASS_LOADER_UNSUPPORTED (106)
The class loader does not support this operation.
Function Specific Agent Errors
The following errors are returned by some JVM TI functions.
They are returned in the event of invalid parameters passed by the
agent or usage in an invalid context.
An implementation is not required to detect these errors.
JVMTI_ERROR_INVALID_THREAD (10)
The passed thread is not a valid thread.
JVMTI_ERROR_INVALID_FIELDID (25)
Invalid field.
JVMTI_ERROR_INVALID_METHODID (23)
Invalid method.
JVMTI_ERROR_INVALID_LOCATION (24)
Invalid location.
JVMTI_ERROR_INVALID_OBJECT (20)
Invalid object.
JVMTI_ERROR_INVALID_CLASS (21)
Invalid class.
JVMTI_ERROR_TYPE_MISMATCH (34)
The variable is not an appropriate type for the function used.
JVMTI_ERROR_INVALID_SLOT (35)
Invalid slot.
JVMTI_ERROR_MUST_POSSESS_CAPABILITY (99)
The capability being used is false in this environment.
JVMTI_ERROR_INVALID_THREAD_GROUP (11)
Thread group invalid.
JVMTI_ERROR_INVALID_MONITOR (50)
Invalid raw monitor.
JVMTI_ERROR_ILLEGAL_ARGUMENT (103)
Illegal argument.
JVMTI_ERROR_INVALID_TYPESTATE (65)
The state of the thread has been modified, and is now inconsistent.
JVMTI_ERROR_UNSUPPORTED_VERSION (68)
A new class file has a version number not supported by this VM.
JVMTI_ERROR_INVALID_CLASS_FORMAT (60)
A new class file is malformed (the VM would return a ClassFormatError).
JVMTI_ERROR_CIRCULAR_CLASS_DEFINITION (61)
The new class file definitions would lead to a circular
definition (the VM would return a ClassCircularityError).
A method in the new class version has different modifiers
than its counterpart in the old class version.
Data Types
JVM TI extends the data types defined by JNI.
JNI Types Used in the JVM Tool Interface
Type
Description
jboolean
Holds a Java programming language boolean.
Unsigned 8 bits.
jint
Holds a Java programming language int.
Signed 32 bits.
jlong
Holds a Java programming language long.
Signed 64 bits.
jfloat
Holds a Java programming language float.
32 bits.
jdouble
Holds a Java programming language double.
64 bits.
jobject
Holds a Java programming language object.
jclass
Holds a Java programming language class.
jvalue
Is a union of all primitive types and jobject. Thus, holds any Java
programming language value.
jfieldID
Identifies a Java programming language field.
jfieldIDs returned by JVM TI functions and events may be
safely stored.
jmethodID
Identifies a Java programming language method, initializer, or constructor.
jmethodIDs returned by JVM TI functions and events may be
safely stored. However, if the class is unloaded, they become invalid
and must not be used.
JNIEnv
Pointer to the JNI function table. Pointer to this (JNIEnv *)
is a JNI environment.
A 64 bit value, representing a monotonically increasing
executable position within a method.
-1 indicates a native method.
See GetJLocationFormat for the format on a
given VM.
An identifier for an event type.
See the Event section for possible values.
It is guaranteed that future versions of this specification will
never assign zero as an event type identifier.
Agents can be informed of many events that occur in application
programs.
To handle events, designate a set of callback functions with
SetEventCallbacks.
For each event the corresponding callback function will be
called.
Arguments to the callback function provide additional
information about the event.
The callback function is usually called from within an application
thread. The JVM TI implementation does not
queue events in any way. This means
that event callback functions must be written
carefully. Here are some general guidelines. See
the individual event descriptions for further
suggestions.
Any exception thrown during the execution of an event callback can
overwrite any current pending exception in the current application thread.
Care must be taken to preserve a pending exception
when an event callback makes a JNI call that might generate an exception.
Event callback functions must be re-entrant. The JVM TI implementation does
not queue events. If an agent needs to process events one at a time, it
can use a raw monitor inside the
event callback functions to serialize event processing.
Event callback functions that execute JNI's FindClass function to load
classes need to note that FindClass locates the class loader associated
with the current native method. For the purposes of class loading, an
event callback that includes a JNI environment as a parameter to the
callback will treated as if it is a native call, where the native method
is in the class of the event thread's current frame.
Some JVM TI events identify objects with JNI references.
All references
in JVM TI events are JNI local references and will become invalid
after the event callback returns.
Unless stated otherwise, memory referenced by pointers sent in event
callbacks may not be referenced after the event callback returns.
Except where stated otherwise, events are delivered on the thread
that caused the event.
Events are sent at the time they occur.
The specification for each event includes the set of
phases in which it can be sent;
if an event triggering activity occurs during another phase, no event
is sent.
A thread that generates an event does not change its execution status
(for example, the event does not cause the thread to be suspended).
If an agent wishes the event to result in suspension, then the agent
is responsible for explicitly suspending the thread with
SuspendThread.
If an event is enabled in multiple environments, the event will be sent
to each agent in the order that the environments were created.
Enabling Events
All events are initially disabled. In order to receive any
event:
If the event requires a capability, that capability must
be added with
AddCapabilities.
In many situations it is possible for multiple events to occur
at the same location in one thread. When this happens, all the events
are reported through the event callbacks in the order specified in this section.
If the current location is at the entry point of a method, the
MethodEntry event is reported before
any other event at the current location in the same thread.
If an exception catch has been detected at the current location,
either because it is the beginning of a catch clause or a native method
that cleared a pending exception has returned, the
exceptionCatch event is reported before
any other event at the current location in the same thread.
If a singleStep event or
breakpoint event is triggered at the
current location, the event is defined to occur
immediately before the code at the current location is executed.
These events are reported before any events which are triggered
by the execution of code at the current location in the same
thread (specifically:
exception,
fieldAccess, and
fieldModification).
If both a step and breakpoint event are triggered for the same thread and
location, the step event is reported before the breakpoint event.
If the current location is the exit point of a method (that is, the last
location before returning to the caller), the
MethodExit event and
the FramePop event (if requested)
are reported after all other events at the current location in the same
thread. There is no specified ordering of these two events
with respect to each other.
Co-located events can be triggered during the processing of some other
event by the agent at the same location in the same thread.
If such an event, of type y, is triggered during the processing of
an event of type x, and if x
precedes y in the ordering specified above, the co-located event
y is reported for the current thread and location. If x does not precede
y, y is not reported for the current thread and location.
For example, if a breakpoint is set at the current location
during the processing of SingleStep,
that breakpoint will be reported before the thread moves off the current
location.
The following events are never considered to be co-located with
other events.
Single step events allow the agent to trace thread execution
at the finest granularity allowed by the VM. A single step event is
generated whenever a thread reaches a new location.
Typically, single step events represent the completion of one VM
instruction as defined in the . However, some implementations
may define locations differently. In any case the
method and location
parameters uniquely identify the current location and allow
the mapping to source file and line number when that information is
available.
No single step events are generated from within native methods.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Breakpoint events are generated whenever a thread reaches a location
designated as a breakpoint with SetBreakpoint.
The method and location
parameters uniquely identify the current location and allow
the mapping to source file and line number when that information is
available.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Field access events are generated whenever a thread accesses
a field that was designated as a watchpoint
with SetFieldAccessWatch.
The method and location
parameters uniquely identify the current location and allow
the mapping to source file and line number when that information is
available.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Field modification events are generated whenever a thread modifies
a field that was designated as a watchpoint
with SetFieldModificationWatch.
The method and location
parameters uniquely identify the current location and allow
the mapping to source file and line number when that information is
available.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Frame pop events are generated upon exit from a single method
in a single frame as specified
in a call to NotifyFramePop.
This is true whether termination is caused by
executing its return instruction
or by throwing an exception to its caller
(see was_popped_by_exception).
However, frame pops caused by the PopFrame
function are not reported.
The location reported by GetFrameLocation
identifies the executable location in the returning method,
immediately prior to the return.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Method entry events are generated upon entry of Java
programming language methods (including native methods).
The location reported by GetFrameLocation
identifies the initial executable location in
the method.
Enabling method
entry or exit events will significantly degrade performance on many platforms and is thus
not advised for performance critical usage (such as profiling).
Bytecode instrumentation should be
used in these cases.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Method exit events are generated upon exit from Java
programming language methods (including native methods).
This is true whether termination is caused by
executing its return instruction
or by throwing an exception to its caller
(see was_popped_by_exception).
The method field uniquely identifies the
method being entered or exited. The frame field provides
access to the stack frame for the method.
The location reported by GetFrameLocation
identifies the executable location in the returning method
immediately prior to the return.
Enabling method
entry or exit events will significantly degrade performance on many platforms and is thus
not advised for performance critical usage (such as profiling).
Bytecode instrumentation should be
used in these cases.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
A Native Method Bind event is sent when a VM binds a
Java programming language native method
to the address of a function that implements the native method.
This will occur when the native method is called for the first time
and also occurs when the JNI function RegisterNatives is called.
This event allows the bind to be redirected to an agent-specified
proxy function.
This event is not sent when the native method is unbound.
Typically, this proxy function will need to be specific to a
particular method or, to handle the general case, automatically
generated assembly code, since after instrumentation code is
executed the function at the original binding
address will usually be invoked.
The original binding can be restored or the redirection changed
by use of the JNI function RegisterNatives.
Some events may be sent during the primordial phase, JNI and
most of JVM TI cannot be used at this time but the method and
address can be saved for use later.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Exception events are generated whenever an exception is first detected
in a Java programming language method.
Where "exception" means any java.lang.Throwable.
The exception may have been thrown by a Java programming language or native
method, but in the case of native methods, the event is not generated
until the exception is first seen by a Java programming language method. If an exception is
set and cleared in a native method (and thus is never visible to Java programming language code),
no exception event is generated.
The method and location
parameters uniquely identify the current location
(where the exception was detected) and allow
the mapping to source file and line number when that information is
available. The exception field identifies the thrown
exception object. The catch_method
and catch_location identify the location of the catch clause,
if any, that handles the thrown exception. If there is no such catch clause,
each field is set to 0. There is no guarantee that the thread will ever
reach this catch clause. If there are native methods on the call stack
between the throw location and the catch clause, the exception may
be reset by one of those native methods.
Similarly, exceptions that are reported as uncaught (catch_klass
et al. set to 0) may in fact be caught by native code.
Agents can check for these occurrences by monitoring
ExceptionCatch events.
Note that finally clauses are implemented as catch and re-throw. Therefore they
will be reported in the catch location.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Exception catch events are generated whenever a thrown exception is caught.
Where "exception" means any java.lang.Throwable.
If the exception is caught in a Java programming language method, the event is generated
when the catch clause is reached. If the exception is caught in a native
method, the event is generated as soon as control is returned to a Java programming language
method. Exception catch events are generated for any exception for which
a throw was detected in a Java programming language method.
Note that finally clauses are implemented as catch and re-throw. Therefore they
will generate exception catch events.
The method and location
parameters uniquely identify the current location
and allow the mapping to source file and line number when that information is
available. For exceptions caught in a Java programming language method, the
exception object identifies the exception object. Exceptions
caught in native methods are not necessarily available by the time the
exception catch is reported, so the exception field is set
to NULL.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Thread start events are generated by a new thread before its initial
method executes.
A thread may be listed in the array returned by
GetAllThreads
before its thread start event is generated.
It is possible for other events to be generated
on a thread before its thread start event.
The event is sent on the newly started thread.
Thread end events are generated by a terminating thread
after its initial method has finished execution.
A thread may be listed in the array returned by
GetAllThreads
after its thread end event is generated.
No events are generated on a thread
after its thread end event.
The event is sent on the dying thread.
A class load event is generated when a class is first loaded. The order
of class load events generated by a particular thread are guaranteed
to match the order of class loading within that thread.
Array class creation does not generate a class load event.
The creation of a primitive class (for example, java.lang.Integer.TYPE)
does not generate a class load event.
This event is sent at an early stage in loading the class. As
a result the class should be used carefully. Note, for example,
that methods and fields are not yet loaded, so queries for methods,
fields, subclasses, and so on will not give correct results.
See "Loading of Classes and Interfaces" in the Java Language
Specification. For most
purposes the ClassPrepare event will
be more useful.
A class prepare event is generated when class preparation is complete.
At this point, class fields, methods, and implemented interfaces are
available, and no code from the class has been executed. Since array
classes never have fields or methods, class prepare events are not
generated for them. Class prepare events are not generated for
primitive classes (for example, java.lang.Integer.TYPE).
This event is sent when the VM obtains class file data,
but before it constructs
the in-memory representation for that class.
This event is also sent when the class is being modified by the
RetransformClasses function or
the RedefineClasses function,
called in any JVM TI environment.
The agent can instrument
the existing class file data sent by the VM to include profiling/debugging hooks.
See the description of
bytecode instrumentation
for usage information.
This event may be sent before the VM is initialized (the primordial
phase). During this time
no VM resources should be created. Some classes might not be compatible
with the function (eg. ROMized classes) and this event will not be
generated for these classes.
The agent must allocate the space for the modified
class file data buffer
using the memory allocation function
Allocate because the
VM is responsible for freeing the new class file data buffer
using Deallocate.
Note that Allocate
is permitted during the primordial phase.
If the agent wishes to modify the class file, it must set
new_class_data to point
to the newly instrumented class file data buffer and set
new_class_data_len to the length of that
buffer before returning
from this call. If no modification is desired, the agent simply
does not set new_class_data. If multiple agents
have enabled this event the results are chained. That is, if
new_class_data has been set, it becomes the
class_data for the next agent.
The order that this event is sent to each environment differs
from other events.
This event is sent to environments in the following order:
The class loader loading the class.
NULL if the bootstrap class loader.
name
const char*
Name of class being loaded as a VM internal qualified name
(for example, "java/util/List"), encoded as a
modified UTF-8 string.
Note: if the class is defined with a NULL name or
without a name specified, name will be NULL.
The VM initialization event signals the start of the VM.
At this time JNI is live but the VM is not yet fully initialized.
Once this event is generated, the agent is free to call any JNI function.
This event signals the beginning of the start phase,
JVM TI functions permitted in the start phase may be called.
In the case of VM start-up failure, this event will not be sent.
The VM initialization event signals the completion of VM initialization. Once
this event is generated, the agent is free to call any JNI or JVM TI
function. The VM initialization event can be preceded by or can be concurrent
with other events, but
the preceding events should be handled carefully, if at all, because the
VM has not completed its initialization. The thread start event for the
main application thread is guaranteed not to occur until after the
handler for the VM initialization event returns.
In the case of VM start-up failure, this event will not be sent.
The VM death event notifies the agent of the termination of the VM.
No events will occur after the VMDeath event.
In the case of VM start-up failure, this event will not be sent.
Note that Agent_OnUnload
will still be called in these cases.
Sent when a method is compiled and loaded into memory by the VM.
If it is unloaded, the CompiledMethodUnload event is sent.
If it is moved, the CompiledMethodUnload event is sent,
followed by a new CompiledMethodLoad event.
Note that a single method may have multiple compiled forms, and that
this event will be sent for each form.
Note also that several methods may be inlined into a single
address range, and that this event will be sent for each method.
These events can be sent after their initial occurrence with
GenerateEvents.
Corresponding location. See
GetJLocationFormat
for the meaning of location.
Capabilities
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Map from native addresses to location.
The native address range of each entry is from
start_address
to start_address-1 of the next entry.
NULL if mapping information cannot be supplied.
compile_info
const void*
VM-specific compilation information.
The referenced compile information is managed by the VM
and must not depend on the agent for collection.
A VM implementation defines the content and lifetime
of the information.
Sent when a compiled method is unloaded from memory.
This event might not be sent on the thread which performed the unload.
This event may be sent sometime after the unload occurs, but
will be sent before the memory is reused
by a newly generated compiled method. This event may be sent after
the class is unloaded.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Compiled method being unloaded.
For identification of the compiled method only -- the class
may be unloaded and therefore the method should not be used
as an argument to further JNI or JVM TI functions.
code_addr
const void*
Address where compiled method code was loaded.
For identification of the compiled method only --
the space may have been reclaimed.
Sent when a component of the virtual machine is generated dynamically.
This does not correspond to Java programming language code that is
compiled--see CompiledMethodLoad.
This is for native code--for example, an interpreter that is generated
differently depending on command-line options.
Note that this event has no controlling capability.
If a VM cannot generate these events, it simply does not send any.
These events can be sent after their initial occurrence with
GenerateEvents.
Sent by the VM to request the agent to dump its data. This
is just a hint and the agent need not react to this event.
This is useful for processing command-line signals from users. For
example, in the Java 2 SDK a CTRL-Break on Win32 and a CTRL-\ on Solaris
causes the VM to send this event to the agent.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Sent when a VM resource needed by a running application has been exhausted.
Except as required by the optional capabilities, the set of resources
which report exhaustion is implementation dependent.
The following bit flags define the properties of the resource exhaustion:
Resource Exhaustion Flags
Constant
Value
Description
JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR
0x0001
After this event returns, the VM will throw a
java.lang.OutOfMemoryError.
JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP
0x0002
The VM was unable to allocate memory from the JavaTM
platform heap.
The heap is the runtime
data area from which memory for all class instances and
arrays are allocated.
Sent when a method causes the virtual machine to allocate an
Object visible to Java programming language code and the
allocation is not detectable by other intrumentation mechanisms.
Generally object allocation should be detected by instrumenting
the bytecodes of allocating methods.
Object allocation generated in native code by JNI function
calls should be detected using
JNI function interception.
Some methods might not have associated bytecodes and are not
native methods, they instead are executed directly by the
VM. These methods should send this event.
Virtual machines which are incapable of bytecode instrumentation
for some or all of their methods can send this event.
Typical examples where this event might be sent:
Reflection -- for example, java.lang.Class.newInstance()
Methods not represented by bytecodes -- for example, VM intrinsics and
J2ME preloaded classes
Cases where this event would not be generated:
Allocation due to bytecodes -- for example, the new
and newarray VM instructions
Allocation due to JNI function calls -- for example,
AllocObject
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
An Object Free event is sent when the garbage collector frees an object.
Events are only sent for tagged objects--see
heap functions.
The event handler must not use JNI functions and
must not use JVM TI functions except those which
specifically allow such use (see the raw monitor, memory management,
and environment local storage functions).
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
A Garbage Collection Start event is sent when a full cycle
garbage collection begins.
Only stop-the-world collections are reported--that is, collections during
which all threads cease to modify the state of the Java virtual machine.
This means that some collectors will never generate these events.
This event is sent while the VM is still stopped, thus
the event handler must not use JNI functions and
must not use JVM TI functions except those which
specifically allow such use (see the raw monitor, memory management,
and environment local storage functions).
This event is always sent as a matched pair with
GarbageCollectionFinish
(assuming both events are enabled) and no garbage collection
events will occur between them.
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
A Garbage Collection Finish event is sent when a full
garbage collection cycle ends.
This event is sent while the VM is still stopped, thus
the event handler must not use JNI functions and
must not use JVM TI functions except those which
specifically allow such use (see the raw monitor, memory management,
and environment local storage functions).
Some agents may need to do post garbage collection operations that
require the use of the disallowed JVM TI or JNI functions. For these
cases an agent thread can be created which waits on a raw monitor,
and the handler for the Garbage Collection Finish event simply
notifies the raw monitor
This event is always sent as a matched pair with
GarbageCollectionStart (assuming both events are enabled).
Optional Functionality: might not be implemented for all
virtual machines.
The following capability
(as returned by
GetCapabilities)
must be true to use this
event.
Last update: 09/05/07
Version: 1.1.109
The JVM TI specification is an evolving document with major, minor,
and micro version numbers.
A released version of the specification is uniquely identified
by its major and minor version.
The functions, events, and capabilities in this specification
indicate a "Since" value which is the major and minor version in
which it was introduced.
The version of the specification implemented by the VM can
be retrieved at runtime with the GetVersionNumber
function.
Version Date
Changes
14 Nov 2002
Converted to XML document.
14 Nov 2002
Elided heap dump functions (for now) since what was there
was wrong.
18 Nov 2002
Added detail throughout.
18 Nov 2002
Changed JVMTI_THREAD_STATUS_RUNNING to JVMTI_THREAD_STATUS_RUNNABLE.
19 Nov 2002
Added AsyncGetStackTrace.
19 Nov 2002
Added jframeID return to GetStackTrace.
19 Nov 2002
Elided GetCurrentFrame and GetCallingFrame functions (for now) since what was there
since they are redundant with GetStackTrace.
19 Nov 2002
Elided ClearAllBreakpoints since it has always been redundant.
19 Nov 2002
Added GetSystemProperties.
19 Nov 2002
Changed the thread local storage functions to use jthread.
Revamp suspend/resume functions.
Add origin information with jvmdi tag.
Misc fixes.
24 Dec 2002
Add semantics to types.
27 Dec 2002
Add local reference section.
Autogenerate parameter descriptions from types.
28 Dec 2002
Document that RunAgentThread sends threadStart.
29 Dec 2002
Remove redundant local ref and dealloc warning.
Convert GetRawMonitorName to allocated buffer.
Add GenerateEvents.
30 Dec 2002
Make raw monitors a type and rename to "jrawMonitorID".
1 Jan 2003
Include origin information.
Clean-up JVMDI issue references.
Remove Deallocate warnings which are now automatically generated.
2 Jan 2003
Fix representation issues for jthread.
3 Jan 2003
Make capabilities buffered out to 64 bits - and do it automatically.
4 Jan 2003
Make constants which are enumeration into enum types.
Parameters now of enum type.
Clean-up and index type section.
Replace remaining datadef entities with callback.
7 Jan 2003
Correct GenerateEvents description.
More internal semantics work.
9 Jan 2003
Replace previous GetSystemProperties with two functions
which use allocated information instead fixed.
Add SetSystemProperty.
More internal semantics work.
12 Jan 2003
Add varargs to end of SetEventNotificationMode.
20 Jan 2003
Finish fixing spec to reflect that alloc sizes are jlong.
22 Jan 2003
Allow NULL as RunAgentThread arg.
22 Jan 2003
Fixed names to standardized naming convention
Removed AsyncGetStackTrace.
29 Jan 2003
Since we are using jthread, removed GetThread.
31 Jan 2003
Change GetFieldName to allow NULLs like GetMethodName.
v40 29 Feb 2003
Rewrite the introductory text, adding sections on
start-up, environments and bytecode instrumentation.
Change the command line arguments per EG discussions.
Add an introduction to the capabilities section.
Add the extension mechanism category and functions.
Mark for deletion, but clarified anyhow, SuspendAllThreads.
Rename IterateOverLiveObjects to IterateOverReachableObjects and
change the text accordingly.
Clarify IterateOverHeap.
Clarify CompiledMethodLoad.
Discuss prerequisite state for Calling Functions.
Clarify SetAllocationHooks.
Added issues ("To be resolved:") through-out.
And so on...
v41 6 Mar 2003
Remove struct from the call to GetOwnedMonitorInfo.
Automatically generate most error documentation, remove
(rather broken) hand written error doc.
Better describe capability use (empty initial set).
Add min value to jint params.
Remove the capability can_access_thread_local_storage.
Rename error JVMTI_ERROR_NOT_IMPLEMENTED to JVMTI_ERROR_MUST_POSSESS_CAPABILITY;
same for *NOT_IMPLEMENTED.
Description fixes.
v42 8 Mar 2003
Rename GetClassSignature to GetClassName.
Rename IterateOverClassObjects to IterateOverInstancesOfClass.
Remove GetMaxStack (operand stack isn't used in JVM TI).
Description fixes: define launch-time, remove native frame pop
from PopFrame, and assorted clarifications.
More phase information - allow "any".
Elide raw monitor queries and events.
Minor description fixes.
v46 12 Mar 2003
Add GetPhase.
Use "phase" through document.
Elide GetRawMonitorName.
Elide GetObjectMonitors.
v47 12 Mar 2003
Fixes from link, XML, and spell checking.
Auto-generate the callback structure.
v48 13 Mar 2003
One character XML fix.
v49 13 Mar 2003
Change function parameter names to be consistent with
event parameters (fooBarBaz becomes foo_bar_baz).
v50 14 Mar 2003
Fix broken link. Fix thread markers.
v51 14 Mar 2003
Change constants so they are under 128 to workaround
compiler problems.
v52 23 Mar 2003
Overhaul capabilities. Separate GetStackTrace into
GetStackTrace and GetStackFrames.
v54 8 Apr 2003
Use depth instead of jframeID to reference frames.
Remove the now irrelevant GetCurrentFrame, GetCallerFrame and GetStackFrames.
Remove frame arg from events.
v55 9 Apr 2003
Remove GetObjectWithAnnotation since tests show bufferred approach more efficient.
Add missing annotation_count to GetObjectsWithAnnotations
v56 10 Apr 2003
Remove confusing parenthetical statement in GetObjectsWithAnnotations
v58 13 Apr 2003
Replace jclass/jmethodID representation of method with simply jmethodID;
Pass JvmtiEnv* as first arg of every event; remove JNIEnv* where inappropriate.
Replace can_access_frames with can_access_local_variables; remove from purely stack access.
Use can_get_synthetic_attribute; fix description.
Clarify that zero length arrays must be deallocated.
Clarify RelinquishCapabilities.
Generalize JVMTI_ERROR_VM_DEAD to JVMTI_ERROR_WRONG_PHASE.
v59 27 Apr 2003
Remove lingering indirect references to OBSOLETE_METHOD_ID.
v60 4 May 2003
Allow DestroyRawMonitor during OnLoad.
v61 7 May 2003
Added not monitor owner error return to DestroyRawMonitor.
v62 13 May 2003
Clarify semantics of raw monitors.
Change flags on GetThreadStatus.
GetClassLoader return NULL for the bootstrap class loader.
Add GetClassName issue.
Define local variable signature.
Disallow zero in annotations array of GetObjectsWithAnnotations.
Remove over specification in GetObjectsWithAnnotations.
Elide SetAllocationHooks.
Elide SuspendAllThreads.
v63 14 May 2003
Define the data type jvmtiEventCallbacks.
Zero length allocations return NULL.
Keep SetAllocationHooks in JVMDI, but remove from JVM TI.
Add JVMTI_THREAD_STATUS_FLAG_INTERRUPTED.
v64 15 May 2003
Better wording, per review.
v65 15 May 2003
First Alpha.
Make jmethodID and jfieldID unique, jclass not used.
v66 27 May 2003
Fix minor XSLT errors.
v67 13 June 2003
Undo making jfieldID unique (jmethodID still is).
v68 17 June 2003
Changes per June 11th Expert Group meeting --
Overhaul Heap functionality: single callback,
remove GetHeapRoots, add reachable iterators,
and rename "annotation" to "tag".
NULL thread parameter on most functions is current
thread.
Add timers.
Remove ForceExit.
Add GetEnvironmentLocalStorage.
Add verbose flag and event.
Add AddToBootstrapClassLoaderSearch.
Update ClassFileLoadHook.
v69 18 June 2003
Clean up issues sections.
Rename GetClassName back to GetClassSignature and
fix description.
Add generic signature to GetClassSignature,
GetFieldSignature, GetMethodSignature, and
GetLocalVariableTable.
Elide EstimateCostOfCapabilities.
Clarify that the system property functions operate
on the VM view of system properties.
Clarify Agent_OnLoad.
Remove "const" from JNIEnv* in events.
Add metadata accessors.
v70 18 June 2003
Add start_depth to GetStackTrace.
Move system properties to a new category.
Add GetObjectSize.
Remove "X" from command line flags.
XML, HTML, and spell check corrections.
v71 19 June 2003
Fix JVMTI_HEAP_ROOT_THREAD to be 6.
Make each synopsis match the function name.
Fix unclear wording.
v72 26 June 2003
SetThreadLocalStorage and SetEnvironmentLocalStorage should allow value
to be set to NULL.
NotifyFramePop, GetFrameLocationm and all the local variable operations
needed to have their wording about frames fixed.
Grammar and clarity need to be fixed throughout.
Capitalization and puntuation need to be consistent.
Need micro version number and masks for accessing major, minor, and micro.
The error code lists should indicate which must be returned by
an implementation.
The command line properties should be visible in the properties functions.
Disallow popping from the current thread.
Allow implementations to return opaque frame error when they cannot pop.
The NativeMethodBind event should be sent during any phase.
The DynamicCodeGenerated event should be sent during any phase.
The following functions should be allowed to operate before VMInit:
Set/GetEnvironmentLocalStorage
GetMethodDeclaringClass
GetClassSignature
GetClassModifiers
IsInterface
IsArrayClass
GetMethodName
GetMethodModifiers
GetMaxLocals
GetArgumentsSize
GetLineNumberTable
GetMethodLocation
IsMethodNative
IsMethodSynthetic.
Other changes (to XSL):
Argument description should show asterisk after not before pointers.
NotifyFramePop, GetFrameLocationm and all the local variable operations
should hsve the NO_MORE_FRAMES error added.
Not alive threads should have a different error return than invalid thread.
v73 7 July 2003
VerboseOutput event was missing message parameter.
Minor fix-ups.
v74 14 July 2003
Technical Publications Department corrections.
Allow thread and environment local storage to be set to NULL.
v75 23 July 2003
Use new Agent_OnLoad rather than overloaded JVM_OnLoad.
Add JNICALL to callbacks (XSL).
Document JNICALL requirement for both events and callbacks (XSL).
Restrict RedefineClasses to methods and attributes.
Elide the VerboseOutput event.
VMObjectAlloc: restrict when event is sent and remove method parameter.
Finish loose ends from Tech Pubs edit.
v76 24 July 2003
Change ClassFileLoadHook event to send the class instead of a boolean of redefine.
v77 24 July 2003
XML fixes.
Minor text clarifications and corrections.
v78 24 July 2003
Remove GetExceptionHandlerTable and GetThrownExceptions from JVM TI.
Clarify that stack frames are JVM Spec frames.
Split can_get_source_info into can_get_source_file_name, can_get_line_numbers,
and can_get_source_debug_extension.
PopFrame cannot have a native calling method.
Removed incorrect statement in GetClassloaderClasses
(see http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79383).
v79 24 July 2003
XML and text fixes.
Move stack frame description into Stack Frame category.
v80 26 July 2003
Allow NULL (means bootstrap loader) for GetClassloaderClasses.
Add new heap reference kinds for references from classes.
Add timer information struct and query functions.
Add AvailableProcessors.
Rename GetOtherThreadCpuTime to GetThreadCpuTime.
Explicitly add JVMTI_ERROR_INVALID_THREAD and JVMTI_ERROR_THREAD_NOT_ALIVE
to SetEventNotification mode.
Add initial thread to the VM_INIT event.
Remove platform assumptions from AddToBootstrapClassLoaderSearch.
v81 26 July 2003
Grammar and clarity changes per review.
v82 27 July 2003
More grammar and clarity changes per review.
Add Agent_OnUnload.
v83 28 July 2003
Change return type of Agent_OnUnload to void.
v84 28 July 2003
Rename JVMTI_REFERENCE_ARRAY to JVMTI_REFERENCE_ARRAY_ELEMENT.
v85 28 July 2003
Steal java.lang.Runtime.availableProcessors() wording for
AvailableProcessors().
Guarantee that zero will never be an event ID.
Remove some issues which are no longer issues.
Per review, rename and more completely document the timer
information functions.
v86 29 July 2003
Non-spec visible change to XML controlled implementation:
SetThreadLocalStorage must run in VM mode.
0.1.87 5 August 2003
Add GetErrorName.
Add varargs warning to jvmtiExtensionEvent.
Remove "const" on the jvmtiEnv* of jvmtiExtensionEvent.
Remove unused can_get_exception_info capability.
Pass jvmtiEnv* and JNIEnv* to the jvmtiStartFunction.
Fix jvmtiExtensionFunctionInfo.func declared type.
Extension function returns error code.
Use new version numbering.
0.2.88 5 August 2003
Remove the ClassUnload event.
0.2.89 8 August 2003
Heap reference iterator callbacks return an enum that
allows outgoing object references to be ignored.
Allow JNIEnv as a param type to extension events/functions.
0.2.90 15 August 2003
Fix a typo.
0.2.91 2 September 2003
Remove all metadata functions: GetClassMetadata,
GetFieldMetadata, and GetMethodMetadata.
0.2.92 1 October 2003
Mark the functions Allocate. Deallocate, RawMonitor*,
SetEnvironmentLocalStorage, and GetEnvironmentLocalStorage
as safe for use in heap callbacks and GC events.
0.2.93 24 November 2003
Add pass through opaque user data pointer to heap iterate
functions and callbacks.
In the CompiledMethodUnload event, send the code address.
Add GarbageCollectionOccurred event.
Add constant pool reference kind.
Mark the functions CreateRawMonitor and DestroyRawMonitor
as safe for use in heap callbacks and GC events.
Clarify: VMDeath, GetCurrentThreadCpuTimerInfo,
GetThreadCpuTimerInfo, IterateOverReachableObjects,
IterateOverObjectsReachableFromObject, GetTime and
JVMTI_ERROR_NULL_POINTER.
Add missing errors to: GenerateEvents and
AddToBootstrapClassLoaderSearch.
Fix description of ClassFileLoadHook name parameter.
In heap callbacks and GC/ObjectFree events, specify
that only explicitly allowed functions can be called.
Allow GetCurrentThreadCpuTimerInfo, GetCurrentThreadCpuTime,
GetTimerInfo, and GetTime during callback.
Allow calling SetTag/GetTag during the onload phase.
SetEventNotificationMode, add: error attempted inappropriate
thread level control.
Remove jvmtiExceptionHandlerEntry.
Fix handling of native methods on the stack --
location_ptr param of GetFrameLocation, remove
JVMTI_ERROR_OPAQUE_FRAME from GetFrameLocation,
jvmtiFrameInfo.location, and jlocation.
Remove typo (from JVMPI) implying that the MonitorWaited
event is sent on sleep.
0.2.94 25 November 2003
Clarifications and typos.
0.2.95 3 December 2003
Allow NULL user_data in heap iterators.
0.2.97 28 January 2004
Add GetThreadState, deprecate GetThreadStatus.
0.2.98 29 January 2004
INVALID_SLOT and TYPE_MISMATCH errors should be optional.
0.2.102 12 February 2004
Remove MonitorContendedExit.
Added JNIEnv parameter to VMObjectAlloc.
Clarified definition of class_tag and referrer_index
parameters to heap callbacks.
0.2.103 16 Febuary 2004
Document JAVA_TOOL_OPTIONS.
0.2.105 17 Febuary 2004
Divide start phase into primordial and start.
Add VMStart event
Change phase associations of functions and events.
0.3.6 18 Febuary 2004
Elide deprecated GetThreadStatus.
Bump minor version, subtract 100 from micro version
0.3.7 18 Febuary 2004
Document that timer nanosecond values are unsigned.
Clarify text having to do with native methods.
Add JVMTI_ERROR_MUST_POSSESS_CAPABILITY to SetEventNotificationMode.
0.3.12 8 March 2004
Clarified CompiledMethodUnload so that it is clear the event
may be posted after the class has been unloaded.
0.3.13 5 March 2004
Change the size parameter of VMObjectAlloc to jlong to match GetObjectSize.
0.3.14 13 March 2004
Added guideline for the use of the JNI FindClass function in event
callback functions.
0.3.15 15 March 2004
Add GetAllStackTraces and GetThreadListStackTraces.
0.3.16 19 March 2004
ClassLoad and ClassPrepare events can be posted during start phase.
0.3.17 25 March 2004
Add JVMTI_ERROR_NATIVE_METHOD to GetLineNumberTable, GetLocalVariableTable,
GetMaxLocals, GetArgumentsSize, GetMethodLocation, GetBytecodes.
0.3.18 29 March 2004
Return the timer kind in the timer information structure.
0.3.19 31 March 2004
Spec clarifications:
JVMTI_THREAD_STATE_IN_NATIVE might not include JNI or JVM TI.
ForceGarbageCollection does not run finalizers.
The context of the specification is the Java platform.
Warn about early instrumentation.
0.3.20 1 April 2004
Refinements to the above clarifications and
Clarify that an error returned by Agent_OnLoad terminates the VM.
0.3.21 1 April 2004
Array class creation does not generate a class load event.
0.3.22 7 April 2004
Align thread state hierarchy more closely with java.lang.Thread.State.
0.3.23 12 April 2004
Clarify the documentation of thread state.
0.3.24 19 April 2004
Remove GarbageCollectionOccurred event -- can be done by agent.
0.3.25 22 April 2004
Define "command-line option".
0.3.26 29 April 2004
Describe the intended use of bytecode instrumentation.
Fix description of extension event first parameter.
0.3.27 30 April 2004
Clarification and typos.
0.3.28 18 May 2004
Remove DataDumpRequest event.
0.3.29 18 May 2004
Clarify RawMonitorWait with zero timeout.
Clarify thread state after RunAgentThread.
0.3.30 24 May 2004
Clean-up: fix bad/old links, etc.
0.3.31 30 May 2004
Clarifications including:
All character strings are modified UTF-8.
Agent thread visibiity.
Meaning of obsolete method version.
Thread invoking heap callbacks,
1.0.32 1 June 2004
Bump major.minor version numbers to "1.0".
1.0.33 2 June 2004
Clarify interaction between ForceGarbageCollection
and ObjectFree.
1.0.34 6 June 2004
Restrict AddToBootstrapClassLoaderSearch and
SetSystemProperty to the OnLoad phase only.
1.0.35 11 June 2004
Fix typo in SetTag.
1.0.36 18 June 2004
Fix trademarks.
Add missing parameter in example GetThreadState usage.
1.0.37 4 August 2004
Copyright updates.
1.0.38 5 November 2004
Add missing function table layout.
Add missing description of C++ member function format of functions.
Clarify that name in CFLH can be NULL.
Released as part of J2SETM 5.0.
1.1.47 24 April 2005
Bump major.minor version numbers to "1.1".
Add ForceEarlyReturn* functions.
Add GetOwnedMonitorStackDepthInfo function.
Add GetCurrentThread function.
Add "since" version marker.
Add AddToSystemClassLoaderSearch.
Allow AddToBootstrapClassLoaderSearch be used in live phase.
Fix historic rubbish in the descriptions of the heap_object_callback
parameter of IterateOverHeap and IterateOverInstancesOfClass functions;
disallow NULL for this parameter.
Clarify, correct and make consistent: wording about current thread,
opaque frames and insufficient number of frames in PopFrame.
Consistently use "current frame" rather than "topmost".
Clarify the JVMTI_ERROR_TYPE_MISMATCH errors in GetLocal* and SetLocal*
by making them compatible with those in ForceEarlyReturn*.
Many other clarifications and wording clean ups.
1.1.48 25 April 2005
Add GetConstantPool.
Switch references to the first edition of the VM Spec, to the seconds edition.
1.1.49 26 April 2005
Clarify minor/major version order in GetConstantPool.
1.1.50 26 April 2005
Add SetNativeMethodPrefix and SetNativeMethodPrefixes.
Reassign GetOwnedMonitorStackDepthInfo to position 153.
Break out Class Loader Search in its own documentation category.
Deal with overly long lines in XML source.
1.1.51 29 April 2005
Allow agents be started in the live phase.
Added paragraph about deploying agents.
1.1.52 30 April 2005
Add specification description to SetNativeMethodPrefix(es).
Better define the conditions on GetConstantPool.
1.1.53 30 April 2005
Break out the GetClassVersionNumber function from GetConstantPool.
Clean-up the references to the VM Spec.
1.1.54 1 May 2005
Allow SetNativeMethodPrefix(es) in any phase.
Add clarifications about the impact of redefinition on GetConstantPool.
1.1.56 2 May 2005
Various clarifications to SetNativeMethodPrefix(es).
1.1.57 2 May 2005
Add missing performance warning to the method entry event.
1.1.58 5 May 2005
Remove internal JVMDI support.
1.1.59 8 May 2005
Add RetransformClasses.
Revamp the bytecode instrumentation documentation.
Change IsMethodObsolete to no longer
require the can_redefine_classes capability.
1.1.63 11 May 2005
Clarifications for retransformation.
1.1.64 11 May 2005
Clarifications for retransformation, per review.
Lock "retransformation (in)capable" at class load enable time.
1.1.67 4 June 2005
Add new heap functionity which supports reporting primitive values,
allows setting the referrer tag, and has more powerful filtering:
FollowReferences, IterateThroughHeap, and their associated
callbacks, structs, enums, and constants.
1.1.68 4 June 2005
Clarification.
1.1.69 6 June 2005
FollowReferences, IterateThroughHeap: Put callbacks in a struct;
Add missing error codes; reduce bits in the visit control flags.
1.1.70 14 June 2005
More on new heap functionity: spec clean-up per review.
1.1.71 15 June 2005
More on new heap functionity: Rename old heap section to Heap (1.0).
1.1.72 21 June 2005
Fix typos.
1.1.73 27 June 2005
Make referrer info structure a union.
1.1.74 9 September 2005
In new heap functions:
Add missing superclass reference kind.
Use a single scheme for computing field indexes.
Remove outdated references to struct based referrer info.
1.1.75 12 September 2005
Don't callback during FollowReferences on frivolous java.lang.Object superclass.
1.1.76 13 September 2005
In string primitive callback, length now Unicode length.
In array and string primitive callbacks, value now "const".
Note possible compiler impacts on setting JNI function table.
1.1.77 13 September 2005
GetClassVersionNumbers() and GetConstantPool() should return
error on array or primitive class.
1.1.78 14 September 2005
Grammar fixes.
1.1.79 26 September 2005
Add IsModifiableClass query.
1.1.81 9 February 2006
Add referrer_class_tag parameter to jvmtiHeapReferenceCallback.
1.1.82 13 February 2006
Doc fixes: update can_redefine_any_class to include retransform.
Clarify that exception events cover all Throwables.
In GetStackTrace, no test is done for start_depth too big if start_depth is zero,
Clarify fields reported in Primitive Field Callback -- static vs instance.
Repair confusing names of heap types, including callback names.
Require consistent usage of stack depth in the face of thread launch methods.
Note incompatibility of JVM TI memory management with other systems.
1.1.85 14 February 2006
Fix typos and missing renames.
1.1.86 13 March 2006
Clarify that jmethodIDs and jfieldIDs can be saved.
Clarify that Iterate Over Instances Of Class includes subclasses.
1.1.87 14 March 2006
Better phrasing.
1.1.88 16 March 2006
Match the referrer_index for static fields in Object Reference Callback
with the Reference Implementation (and all other known implementations);
that is, make it match the definition for instance fields.
In GetThreadListStackTraces, add JVMTI_ERROR_INVALID_THREAD to cover
an invalid thread in the list; and specify that not started threads
return empty stacks.
1.1.89 17 March 2006
Typo.
1.1.90 25 March 2006
Typo.
1.1.91 6 April 2006
Remove restrictions on AddToBootstrapClassLoaderSearch and
AddToSystemClassLoaderSearch.
1.1.93 1 May 2006
Changed spec to return -1 for monitor stack depth for the
implementation which can not determine stack depth.
1.1.94 3 May 2006
Corrections for readability and accuracy courtesy of Alan Pratt of IBM.
List the object relationships reported in FollowReferences.
1.1.95 5 May 2006
Clarify the object relationships reported in FollowReferences.
1.1.98 28 June 2006
Clarify DisposeEnvironment; add warning.
Fix typos in SetLocalXXX "retrieve" => "set".
Clarify that native method prefixes must remain set while used.
Clarify that exactly one Agent_OnXXX is called per agent.
Clarify that library loading is independent from start-up.
Remove ambiguous reference to Agent_OnLoad in the Agent_OnUnload spec.
1.1.99 31 July 2006
Clarify the interaction between functions and exceptions.
Clarify and give examples of field indices.
Remove confusing "That is" sentence from MonitorWait and MonitorWaited events.
Update links to point to Java 6.
