JRockit 5.0 - The JVM at Your Fingertipsby Marcus Hirt12/12/2005 AbstractThe BEA JRockit Java virtual machine (JVM) offers more than just a performance advantage. This article discusses some manageability and usability features available in the 5.0 R26 version of JRockit. In particular, it provides a brief look at the JRockit Mission Control suite of analysis tools, the experimental headless mode for the JRockit Management Console, interacting with the JVM using the Ctrl-Break Handler, JRCMD, Heap View, and code coverage. IntroductionThe JRockit JVM is not only fast, but it also comes with JRockit Mission Control, a suite of analysis tools for performing runtime analysis and memory leak detection. The JRockit Management Console is included with the JRockit JDK. In this article I discuss an experimental headless mode for the JRockit Management Console that can be used for interfacing with JRockit JMX-based management agents from the command line. The Ctrl-Break Handler provides a means to send a variety of advanced commands to JRockit even after it has started. These commands can even be invoked remotely, as I show later in the article. I conclude with a discussion of the experimental code coverage that JRockit provides right out of the box. For more information on BEA JRockit, stay tuned to the JRockit Product Center on dev2dev. I'll begin with a quick overview of the established manageability tools available for the JRockit JVM, and then I'll move on to less documented and experimental manageability features. JRockit Mission ControlThe JRockit Mission Control tool suite was introduced with the JRockit R26.0.0 release, and includes tools to monitor, manage, profile, and eliminate memory leaks in your Java applications without introducing the performance overhead normally associated with tools of this type. Mission Control's low performance overhead is a result of using data collected as part of JRockit's normal adaptive dynamic optimization. This also eliminates the problem with the Heisenberg anomaly that can occur when tools using byte code instrumentation alter the execution characteristics of the system. JRockit Mission Control functionality can always be available on demand, and the small performance overhead is only in effect while a tool is running. These properties make the JRockit Mission Control tools uniquely positioned to be used on systems running in production. The following tools are included in JRockit Mission Control:
For more information about JRockit Mission Control, read the article An Introduction to JRockit Mission Control, or visit the JRockit Mission Control page on dev2dev. The JRockit Management Console Headless Mode (Experimental)The JRockit Management Console is a tool to monitor running JRockits. It consists of two parts: a JMX agent running in the JVM process, and a standalone client with a graphical user interface (see An Introduction to JRockit Mission Control for further details on this and other aspects). The user interface can, among other things, draw graphs of any numerical attribute of any MBean deployed in the Java virtual machines it is connected to. Graphic-intensive applications can be very resource hungry, and the JRockit Management Console is no exception. A text-only mode has been introduced so you can use the notification functionality and data collection facilities of the Management Console without incurring the overhead of the GUI. With the headless console a number of new command-line parameters have been introduced. These are also applicable to the GUI version of the console. The arguments are:
Here is an example that will start the management console in headless mode, read the specified settings file, try to connect to all previously specified JRockits, and actively search for new ones using JRockit Discovery Protocol (or JDP, as discussed below). After 30 seconds it will start issuing Ctrl-Breaks to all connected JRockits in one-minute intervals. After an hour it will automatically shut down. All notification rules that were previously added to specific connections, either by using the GUI or directly editing the settings file, will be active. java -jar ManagementConsole.jar -headless -settings C:\Headless\consolesettings.xml -connectall -autoconnect -uptime 3600 -useraction ctrlbreak 30 60 User actions are plug-in classes that can interact with a set
of connections in the JRockit Management Console, and also use the
console settings file to store configuration data. The user actions are
displayed under the Plugins menu in the graphical user interface of the
JRockit Management Console, and are also available from the headless
mode. Two default user actions are supplied with the console: the Writing your own user action is quite easy. First, you create a
subclass of package com.example.useractions;
import java.io.IOException;
import java.util.List;
import com.jrockit.console.rjmx.CommonRJMXNames;
import com.jrockit.console.rjmx.RJMXConnectorModel;
import com.jrockit.console.useractions.AbstractUserAction;
/**
* This is a simple user action, getting stackdumps from
* the selected JRockits and printing them on stdout.
*
* @author Marcus Hirt
*/
public class MyUserAction extends AbstractUserAction
{
public void executeAction(List<RJMXConnectorModel> connections)
{
for (RJMXConnectorModel connection : connections)
{
if (connection.isConnected())
{
try
{
System.out.println(CommonRJMXNames.getThreadMXBean(connection).getThreadStackDump());
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
}
}
Next, you need to enter a deployment descriptor in the <user_action> <user_action_class>com.example.useractions.MyUserAction</user_action_class> <user_action_name>stackdump</user_action_name> <user_action_menu_name>Stack Dump on stdout</user_action_menu_name> <user_action_description>Gets a stack dump from the selected JRockit(s), and dumps it on stdout.</user_action_description> </user_action> This will also make your user action visible in the user interface under the Plugins menu. If you have settings/state you need to load/store from the settings
file when the console starts or exits, you can simply override /**
* @see com.jrockit.console.util.XmlEnabled
* #exportToXml(org.w3c.dom.Element)
*/
public void exportToXml(Element parentNode)
{
super.exportToXml(parentNode);
XmlToolkit.setSetting(parentNode, MY_PROPERTY, m_myVal);
}
/**
* @see com.jrockit.console.util.XmlEnabled
* #initializeFromXml(org.w3c.dom.Element)
*/
public void initializeFromXml(Element parentNode)
{
super.initializeFromXml(parentNode);
m_myVal = XmlToolkit.getSetting(parentNode,
MY_PROPERTY, DEFAULT_MY_VALUE));
}
Note that the user action name is the name by which you will refer to the user action when using the launcher startup parameters. The menu name is the name that will be displayed in the GUI menu. See the user action docs and the JLMEXT docs for more information. Note that this is experimental functionality; the supplied documentation is rather spartan. Writing custom notification actions and constraints is done in a similar fashion. See the Management Console User Guide for more information. JRockit Discovery Protocol (JDP)JDP (JRockit Discovery Protocol) is a simple and efficient protocol for letting the JRockit Management Server multicast its presence to the Management Console. The system properties in the two tables below control the behavior of the JDP for the server and the client, respectively. Management Server JDP properties
Management Console JDP properties
Here is an example of the minimum number of parameters needed to start up JRockit with the server side of the JDP turned on: java -Xmanagement -Djrockit.managementserver.autodiscovery=true <your program> The Ctrl-Break HandlerHave you ever wished for an easy way of communicating with the JVM
after it has been started? Let's say you forgot to add the Usage
JRockit first will search for the file in the current working directory. If the file isn't found, JRockit will look in the directory of the JVM. If the file isn't found there, JRockit will fall back to generating a normal thread stack dump. JRockit will read the act file each time ctrl-break is pressed, so you can reconfigure the file at your leisure while JRockit is still running. Here is an example act file that first prints a timestamp, then the command line used to start JRockit, and finally a thread stack dump. It also contains a list of useful commands you can use in your act file: # Example ctrlhandler.act file timestamp command_line print_threads stop # set_filename filename=<file> [append=true] # Sets the file that all handlers following this command will # use for printing. You can have several set_filename commands # in a file. It takes two arguments: filename and an optional # append to specify if you want to append to the file # or overwrite it. Default is to overwrite the file. # timestamp # Prints a timestamp. # print_threads # The normal thread dump. # verbosity [args=<components>] [filename=<file>] # Changes the verbosity level normally specified with -Xverbose. # version # Prints JRockit version information. # command_line # Prints the command line used to start JRockit. # print_object_summary # Prints heap usage statistics (how much heap is used per class), # together with a delta on how much this has changed since # the last invocation of this ctrl-break handler. # print_memusage # Prints a memory usage report of how JRockit is using # the memory. # heap_diagnostics # Prints a detailed report of the heap, including ascii graphics # over the heap layout. # print_class_summary # Prints all loaded classes. # print_utf8pool # Print all UTF8 strings. # jrarecording [filename=<file>] [time=<time>] [nativesamples=true] # Starts a JRA recording. # run_optfile [filename=<file>] # See OptFile. # start_management_server # Starts the new JMX-based management agent. # kill_management_server # Stops the management agent. # start_rmp_server # Starts the old management server (actually the listening # socket that in turn starts servers whenever a connection # is established). # kill_rmp_server # Stops the old management server (actually shuts down the # listening socket). The only reason it isn't named # kill_rmp_server is that stop is a reserved keyword # that stops the parsing of the act file. ;) # help [ctrl-break handler] # Prints all available ctrl-break handlers if no argument # is specified, or help for the specified ctrl-break handler. # memleakserver [port=<port>] # Toggles the memleakserver. If it hasn't been started # it will be started. If it has already started, it will be # shut down. The default port is 7095. # verbose_referents action=[heap|full|nursery|start|stop] # Print verbose reference information. # Parameters: # action=[heap|full|nursery|start|stop] # heap - trigger a heap collection and output reference # information # full - trigger a full heap collection (clears softly # reached soft referents) # nursery - trigger a nursery collection (heap collection # if running without nursery) # start - start writing reference information to default # verbose stream # stop - stop writing reference information # print_exceptions # exceptions=[true|all|false] stacktraces=[true|all|false] # Enable printing of Java exceptions thrown in the VM. # Parameters: # exceptions - print exceptions # stacktraces - print exceptions with stacktraces # At least one of the parameters is required. # Values for the parameters can be "true|all|false" # true - print all exceptions # except java/util/EmptyStackException, # java/lang/ClassNotFoundException and # java/security/PrivilegedActionException # all - print all exceptions # false - don't print exceptions # To turn exception printing off completely you need to set # exceptions = false even if it was turned # on by stacktraces = true. JRCMDA new convenient way of invoking the Ctrl-Break Handler is to use
the JRCMD utility, available in the Usagejrcmd <PID> <command> <parameters>
If no options are specified (or only To list what Ctrl-Break Handlers are available in a certain JRockit, you can use the help command: jrcmd <PID> help To get help on a specific Ctrl-Break Handler, just add the name of the Ctrl-Break Handler you need help on, for example: jrcmd 0 help kill_management_server You can also use JRCMD to list the performance counters of a specified process: jrcmd <PID> -l Invoking Ctrl-Break Handlers RemotelyYou can use the JRockit Management Console to invoke Ctrl-Break Handlers remotely. There is an operation on the JRockitConsoleMBean, named runCtrlBreakHandlerWithResult. The JRockit Management Console can invoke operations on MBeans from the attribute browser. Here is a step-by-step description of how to invoke the Ctrl-Break Handler:
Try entering "help" as the parameter. This will list all available Ctrl-Break Handlers, as shown in Figure 1.
Heap View (Experimental)When analyzing how your application performs with a certain garbage collection strategy, it can be very helpful to get a snapshot of the heap after every GC. This helps developers study data such as fragmentation/compaction and how the algorithm is performing in general. The amount of data in these snapshots is too large to make sense of by just inspecting it, so the JRockit team has a small tool that provides a graphical representation that is much easier to interpret. Figure 2 shows an example of a snapshot (made using a very early, pre-release version of JRockit 1.4.2):
Every row represents a garbage collection. The left side is the beginning of the heap, and the right side is the end. On the right side of the heap display is a configurable graph. Solid white areas represent free heap, and black areas are well-compacted areas (that is, areas filled with objects). Grayish areas are fragmented. The red, yellow, and green area is the configurable graph. It is possible to specify what to display in the configurable graph from the command line. The tool is still rough and not very user friendly, and there are doubts as to how useful it is for end users of JRockit, so this is a tool that may very well never reach general availability. Code Coverage (Experimental)Many developers use code coverage analysis to study things such as how much, and exactly what part, of the code base is being run when they use their application in a certain way. Testers like using code coverage as a measure of how much of an application is covered by their test suites. For large applications, though, the performance cost incurred by the code coverage tool is often prohibitive. JRockit has high-performance line code coverage built in. When running with code coverage turned on, the code is generated with traps that register the line hit. Once a line has been hit, and recorded, the trap is removed and JRockit can continue to run at almost full speed. To make JRockit record code coverage data you must specify a command-line option. Usage-Xcodecoverage You use the following system properties to control the behavior:
Here are the code coverage-specific parameters that were used to generate the data shown in the picture below: -Xcodecoverage -Djrockit.codecoverage.filter=
com/jrockit/console/*;com/jrockit/common/*
-Djrockit.codecoverage.outputfile=console_coverage.txt
Internally, a small code coverage tool interprets the data generated by JRockit, as illustrated in Figure 3.
ConclusionBeing in control of the Java runtime puts BEA in a unique position to deliver low-overhead management and monitoring features for the Java platform. Many interesting manageability and usability features are being developed for BEA JRockit. A few of them became available with JRockit Mission Control, included with JRockit 5.0 R26, and more are just around the corner. For additional information, see the Mission Control home page. References
Marcus Hirt is one of the founders of Appeal Virtual Machines, the company that created the Java Virtual Machine JRockit. He is currently working as Engineering Manager for the JRockit Mission Control team. Return to dev2dev. 
Showing messages 1 through 3 of 3.
|
Article Tools Related Products Check out the products mentioned in this article:Bookmark Article
|
