Analysis of the visibility features of Java SE 6 in Solaris

The Java Platform Standard Edition (Java SE) 6, the code name "Mustang", is the latest Java SE release (under development). Java SE 6 Source and binary code can be downloaded from the www.Java.net. The Java SE 6 platform will not be officially released until the fall of 2006. However, now you can download the beta version of the demo Java SE 6.

The Java SE 6 platform provides a variety of observable (observability) tools, many of which can be run on the system, and only a handful of these tools are used to suspend processes or core replication processing. Therefore, in this article, we will analyze the effect of these observable tools on the process.

　　 an observable tool in the Java SE 6 platform-dtrace

Many of the observable improvements have been introduced in the Java SE 6 software. Although most of these can be applied to all platforms, some of these improvements are only specific to the Solaris operating system (specifically for Solaris 10 and later). In the J2SE 5.0 platform, a new dynamic trace (DTrace) behavior--jstack is introduced. As we have already learned, Jstack can print mixed-mode stack trace information (both Java and Native-C + + languages are displayed in frames). When a pollsys system call is emitted from a given Java process, the following D script outputs trace information for the mixed-mode stack:

#!/usr/sbin/dtrace-s
Syscall::p ollsys:entry
/pid = = $/{
/* Print up to 50 frames/*
Jstack (50);
}
Here is the result of the script above:

Libc.so.1 ' __pollsys+0xa
Libc.so.1 ' poll+0x52
libjvm.so ' int os_sleep (long long,int) +0xb4
libjvm.so ' int os::sleep (Thread*,long long,int) +0x1ce
Libjvm.so ' JVM_SLEEP+0X1BC
Java/lang/thread.sleep
Dtest.method3
Dtest.method2
Dtest.method1
Dtest.main
[... Space limit, the deletion of some output results ...]
In fact, Jstack is a useful starting point for the Java observable in the Solaris OS and above versions. However, the Java SE 6 is more than that, and it adds a lot of dtrace probe to the visibility of Java Virtual Machine (JVM) and the observable nature of Java applications. Two JVM-specific dtrace providers-hotspot and Hotspot_jni are added to the Java SE 6 release.

　　 ii. hotspot Providers

Hotspot providers have added a number of probes, which can be roughly categorized as follows:

· VM Life cycle probe-VM boot, shutdown event

· Thread life cycle Probes-thread start, stop, etc.

· Class load Probes-a Java class loading or unloading

· Garbage collection Probe-GC start, end

· Method compile probe-java byte code-to-native code compilation ("Hotspot compilation")

· Monitor probe-java monitor competitive entrances, notices, notices, all, etc.

· Application probes-java Object allocation, Java method entry/return, etc.

For more detailed information on these probes, please refer to Keith McGuigan's blog. Here are some examples of using these probes.

(i) Print the name of a Java thread

Hotspot$1:::thread-start {
Self->ptr = (char*) copyin (arg0, arg1+1);
SELF->PTR[ARG1] = ' the ';
Self->threadname = (string) self->ptr;
printf ("Thread%s started\n", self->threadname);
}

(ii)-verbose:class equivalents in D scripts

You may have used the-verbose:class JVM option. This option enables the JVM to print a trace message when a Java class is loaded or unloaded. Here's what happens when you use DTrace to get the same results:

* * When each class is loaded, print out their respective names.
hotspot$1:::class-loaded {
Self->str_ptr = (char*) copyin (arg0, arg1+1);
SELF->STR_PTR[ARG1] = ' the ';
Self->name = (string) self->str_ptr;
printf ("Class%s loaded\n", self->name);
}
(iii) Print stack trace information in the exception (in addition to blending mode)

The Throwable.printstacktrace () method prints a stack trace that contains a Java frame. This d script will print Java code, Java Native Interface (JNI) code, C + + code, and all frames of the OS C + + code-Whenever an exception is thrown.

Hotspot$1:::method-entry {
Self->ptr = (char*) copyin (arg1, arg2+1);
SELF->PTR[ARG2] = ' the ';
Self->classname = (string) self->ptr;
Self->ptr = (char*) copyin (Arg3, arg4+1);
SELF->PTR[ARG4] = ' the ';
Self->methodname = (string) self->ptr;
}
Hotspot$1:::method-entry
/Self->classname = = "Java/lang/throwable" && self->methodname = = "<init>"/{
Jstack ();
}
All exceptions and errors in Java code derive directly or indirectly from java.lang.Throwable, so all the exception constructors will eventually invoke the Java.lang.Throwable constructor. This d script creates a method entry probe-uses a filter for the constructor (note that,<init> is the internal name of the constructor method). When this constructor is invoked, the Jstack () behavior prints the mixed-mode stack trace.

(iv) Java heap histogram

We can use the Object-alloc probe to build a Java heap histogram, as follows:

Hotspot$1:::object-alloc {
Self->str_ptr = (char*) copyin (arg1, arg2+1);
SELF-&GT;STR_PTR[ARG2] = ' the ';
Self->classname = (string) self->str_ptr;
@allocs_count [Self->classname] = count ();
@allocs_size [Self->classname] = SUM (ARG3);
}

(v) HOTSPOT_JNI providers

JNI allows a Java program to interact with C + + code. If you want to observe the interaction of Java code with native code, you can use the HOTSPOT_JNI provider. For each JNI function input/output, this provider will expose a probe.

(vi) Effects of using DTrace in Java programs

DTrace is designed as a production-mode observable system (with 0 effects when not in use). When the probe is supported, the observed system is unaffected.

Because most of the JVM probes exposed by hotspot and hotspot_jni providers are lightweight, they can be used in production machines. However, some probes exposed by hotspot providers require a specific command-line option "-xx:+extendeddtraceprobes" to start the JVM. These probes are: Java Method entry/method return, object assignment and Java monitor probes. Note that these probes all require changes to the hotspot bytecode interpreter and the hotspot compiler (bytecode-to-machine code compilers). Even if they are not supported, the cost of these probes is more expensive.

　　 Iii. observable tools in the Java SE 6 platform

In addition to the integration of DTrace with Java technology, the Java SE 6 release contains a number of other observable tools. These tools are summarized below, which also contains a few more detailed link descriptions.

(i) Jconsole

Jconsole uses the Extensible Java Management Extension (JMX) tool of the JVM to provide information about the performance and resource consumption of applications running on the Java platform.

In the J2SE 5.0 software, you need to start an application that is monitored using the-dcom.sun.management.jmxremote option. Note: In the Java SE 6 software, this requirement is no longer available. When you start the application, you do not need a specific command-line option.

Application in the production system

Jconsole launches a JMX agent inside the JVM of the observed Java program. Running another part of the code has only a slight effect-but the impact is minimal.

In addition, although jconsole is useful in monitoring the development of local applications and rapid prototyping development, it is not recommended in actual application systems. The reason is that jconsole itself consumes a lot of system resources. The approach we recommend is to use remote monitoring to isolate the jconsole application from the monitored system. Therefore, it is better to use Jconsole in remote mode for application system. For secure remote monitoring, you can use security options.

(ii) JPS

JPS is equivalent to the Solaris Process tool PS. For more information, please refer to "Jps-java Virtual Machine Process Status Tool."

Not like "pgrep java" or "Ps-ef | grep Java, JPS does not use the application name to find JVM instances. Therefore, it looks for all Java applications, including even those that do not use the Java Executive Body (for example, custom initiators). In addition, JPS finds only the current user's Java process, not all processes in the current system.

(iii) Jstat

JSTAT displays performance statistics for a measurement (instrumented) Java hotspot virtual Machine (refer to Jstat-java virtual Machine Statistics, monitoring Tool). For more detailed information on performance counters, refer to Code Sample-jvmstat 3.0.

(d) jstatd

JSTATD is a Java remote method call (RMI) server application that monitors the creation and termination of Java hotspot virtual machines and provides an interface to allow remote monitoring tools to be attached to the JVM running on the local host (refer to the Jstatd-virtual Machine jstat Daemon ").

Use in the application system

JPS and other Jvmstat utilities use extremely lightweight observation mechanisms. A small portion of shared memory is allocated by the JVM, and performance counters are allocated from this portion of memory. The JVM subsystem updates performance counters based on events of interest to them. The client tool is solely responsible for reading from the shared memory segment asynchronously. Therefore, overall, the use of Jvmstat to monitor the effect is very small.

　　 Four, the Java SE 6 platform for the postmortem of the observable tool

Java SE 6 supports the postmortem observable tool-it can get information from a pending Java process or Java core replication. These tools (except Jhat) use the Solaris Libproc Library to attach to and read the observed program. During the observation, the target program is suspended. These tools are available when the Java process is suspended or when a core replication occurs from a Java process. Whenever possible, consider using Gcore to capture a snapshot of the core replication of the system and use any of the following tools to "off-line" analysis of core replication.

(i) Jinfo

Jinfo prints a given Java process or core file or Java configuration information for a remote debugging server. Configuration information includes Java System Properties and JVM command-line flags (for more information, refer to "jinfo-configuration info").

(ii) Jmap

Jmap: If the tool does not run with any options (except the PID or Core option), it displays information similar to the output of the Solaris Pmap tool. This tool supports several other options for the observable nature of the Java heap.

In the Java SE 6 platform, a new-dump option is added. This allows Jmap to copy Java heap information to a file, and then we can analyze it using the new Jhat command (see section below).

Instead of using the Solaris Libproc to implement real-time processing, the Jmap-dump option runs a small piece of code in the currently running JVM to implement heap replication. Since this kind of heap copy code runs inside the JVM, the speed is relatively fast. The effect of heap replication is roughly equivalent to implementing a "full GC" (garbage collection of the entire heap), plus writing the contents of the heap to a file. Another possible way to implement heap replication is to use Gcore for core replication and run "Jmap-dump" (This contrasts with core replication that runs in "offline" mode).

(iii) Jstack

Jstack is equivalent to the Solaris Pstack tool. Jstack Print stack trace information for all Java threads (optionally including native frame information), refer to the jstack-stack trace. Information about locks and deadlocks can also be printed, please refer to java.util.concurrent locks.

(d) Jsadebugd

JSADEBUGD is attached to a Java process or core file and acts as a debugging server. Remote clients, such as Jstack, Jmap, and jinfo, can be attached to the server through Java RMI.

(v) jhat

Jhat is a Java heap replication browser. This tool analyzes Java heap copy files (for example, generated by the "Jmap-dump" above). Jhat launches a Web server that allows objects in the heap to be parsed in a Web browser. This tool is not intended for use in application systems but for "off-line" analysis. The Jhat tool is platform independent, meaning it can be used to observe heap replication on any platform. For example, it is possible to use Jhat on a Linux system to observe a heap replication that is generated on the Solaris OS.