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:
The VM has two built-in probes for initialization: hotspot:::vm-init-begin
. 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.
Corresponds to hotspot::vm-shutdown
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
The VM built-in probe is hotspot:::thread-stop
and has the same parameters as the hotspot:::thread-start
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.
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
. 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
. 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
. 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]
, 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
, 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
dvm:::method-entry and dvm:::method-return
The corresponding VM probes, hotspot:::method-entry
, 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
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.