Friday Aug 11, 2006

DVM agent to Hotspot 6.0 DTrace probe migration guide

As of the 6.0 VM, a number of dtrace probes have been built-in so that you can use them without running an agent, and for most probes, without running with any special command-line arguments.

A full description of all the available probes and their arguments is available here: DTrace probes in 6.0

The built-in, always-on probes in the VM correspond closely to the probes avialable in djvm, but the arguments are slightly different and some of the probes need to be enabled with special command-line flags (which results in some performance degredation, but much less than running with the agent). There are also additional probes for every JNI method's entry and return point.

One major difference between djvm and the built-in probes is in the way they pass string arguments. While djvm passes a null-terminated ASCII (or UTF8) string, the built-in probes pass length-deliminated UTF8 strings. In order to correctly read the strings you have to use the copyinstring() primitive which takes a length argument, since there is no guarantee of an ending null.

Here's a quick summary of the probes in djvm and the corresponding built-in Hotspot probe:

dvm::::vm-init

The VM has two built-in probes for initialization: hotspot:::vm-init-begin and hotspot:::vm-init-end. The begin probe is fired as soon as the VM starts, while the end probe is fired when the VM is ready to start executing Java code.

dvm:::vm-death

Corresponds to hotspot::vm-shutdown.

dvm:::thread-start(char\* thread_name)

The VM built-in probe that corresponds to this is hotspot:::thread-start and it has 5 arguments, the first two are a string/length pair that indicate the name of the thread. The third argument is the Java thread id, the forth is the native thread id, and the last is a boolean value that indicates whether or not the thread is a daemon thread

dvm:::thread-end

The VM built-in probe is hotspot:::thread-stop and has the same parameters as the hotspot:::thread-start probe.

dvm:::class-load(char\* class_name)

The VM built-in probe that corresponds to this is hotspot:::class-loaded which has a few additional parameters. The first two are the string/length pair for the class name. The third argument is a unique integer identifier for the class loader which loaded the class, and the last is a boolean which indicates whether or not the class is a shared class.

dvm:::class-unload(char\* class_name)

The VM build-in probe which corresponds to this is hotspot:::class-unloaded which has the same paramters as hotspot:::class-loaded.

dvm:::gc-start(), dvm:::gc_finish(), and dvm::gc-stats(long objs, long space)

The VM has two top-level probes to indicate when a garbage collection phase has started and finished: hotspot:::gc-begin and hotspot:::gc-end. The gc-begin probe has a boolean parameter which indicates if the GC cycle was started due to a full heap or by user request. As each memory pool is collected, additional probes fire which contain the statistics for that pool: hotspot:::mem-pool-gc-begin and hotspot:::mem-pool-gc-end. These probes have 8 parameters. The first two are the string/length pair for the pool manager's name. The next two are the string/length pair for the pool name. The rest are long integers that contain the stats of the pool: initial size, used space, committed space, and maximum size.

dvm:::object-alloc(char\* class_name, long size) and dvm:::object-free(char\* class_name)

The VM has a built-in probe for allocation, hotspot:::object-alloc, but it must be enabled manually when the VM starts via the command-line flag -XX:+DTraceAllocProbes or -XX:+ExtendedDTraceProbes. The VM has no corresponding object-free probe for performance reasons. The object-alloc probe's first parameter is the Java thread id which is performing the allocation. The next two arguments are the string/length pair for the name of the class of which a new instance is being allocated. The last parameter is the size of the instance.

dvm::monitor-contended-enter[ed] and dvm::monitor-wait[ed]

The VM probes probes for contended enter and wait as hotspot:::monitor-contended-enter[ed] and hotspot:::monitor-wait[ed], but the first two parameters are the Java thread id and a unique monitor id. The third and fourth parameters are the string/length pair for the name of the class being acted upon. The hotspot:::monitor-wait probe has an additional parameter which indicates the timeout. The VM provides additional probes for contended-exit and notify events: hotspot:::monitor-contended-exit, hotspot:::monitor-notify, and hotspot:::monitor-notifyAll. These probes have the same parameters the contended enter probes. All of the monitor-releted probes in the VM are only enabled if the VM has been started with the -XX:+DTraceMonitorProbes or -XX:+ExtendedDTraceProbes command-line flag.

dvm:::method-entry and dvm:::method-return

The corresponding VM probes, hotspot:::method-entry and hotspot:::method-return, have the Java thread id as the first argument, followed by 3 string/length pairs for the class and method names and the signature. The built-in VM probes are only enabled if the -XX:+DTraceMethodProbes or -XX:+ExtendedDTraceProbes command-line arguments are provided.

Other built-in VM probes

The VM has additional built-in probes with no dvm equivalent for classloading, method compilation, and for tracking the entries and returns from JNI methods. Please refer to the beforementioned documentation for additional details.
About

kamg

Search

Top Tags
Categories
Archives
« August 2006 »
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today