Here are the ones I am involved in:

Other exciting sessions:

This is basically a very short tutorial on how to use them.

Install the PDE plug-ins

1. First make sure you have Eclipse 3.3 or 3.4 installed.
   You will need the plug-in builder edition.
2. Next make sure that you have installed JRockit Mission Control 3.1.0 into your Eclipse.
   The update site is here: http://www.oracle.com/technology/software/products/jrockit/missioncontrol/updates/base/3.1.0/eclipse/index.html
3. Next install the PDE plug-ins from the experimental update site.
   The experimental update site is here:
   http://www.oracle.com/technology/software/products/jrockit/missioncontrol/updates/experimental/3.1.0/eclipse/index.html

Worth noting here is that if you fall for the temptation to also include the JConsole meta plug-in from the experimental update site, you need to be running your Eclipse on a JRockit 1.6 based JVM for the plug-in to work.

Creating a JRockit Mission Control Console PDE project

In this example we’ll create an additional tab in the JRockit Mission Control console. The tab will subscribe to one or more values from the JVM, depending on which wizard you choose.

1. Create a new Plug-in project by selecting File->New->Project… and then selecting Plug-in Project.
   If that alternative is not available to you, ensure that you have installed the Plug-in Builder version of Eclipse.
2. Name your Plug-In Project by entering the Project Name in the New Plug-in Project Wizard. Then click next.
   (e.g. com.example.mc.testtab)
3. Review the details in the Plug-in Content page and then click next.
4. Select either the Mission Control Complex or Simple Tab wizard.
5. Review the details in the tab wizard, then click finish.

You now have a project which should compile properly. The plug-in adds a tab to the JRockit Mission Control Console. There are other wizards, for instance one that add actions to the triggers tab in the the JRockit Mission Control Console.

Together with exposing these extension points, we also wanted to provide plug-ins that facilitates building extensions for JRMC. Since these plug-ins, strictly speaking, are not part of the JRockit Mission Control product, we’ve tried to come up with a good way for distributing them.

Today we released the Experimental Update Site for JRockit Mission Control. It contains plug-ins for Eclipse and/or JRMC that either extends, or makes it easier to extend, JRockit Mission Control. In this first release, there is a PDE plug-in that provides wizards for extending the JRockit Mission Control console in various ways. There is also a JConsole meta plug-in, that allows you to run JConsole plug-ins in JRockit Mission Control. IMHO, using the PDE-plug-ins to build a native JRMC version of the plug-in is the better way to go. ;)

Everything in the experimental update site is provided as is – it is unsupported functionality, and the plug-ins may be revised and updated without notice. Please use the forum if you have any questions or want to report problems with these plug-ins.

Have fun!

Hope you’ll like it! :)

You can download it from the JRockit Mission Control Home Page, either as a stand alone application, or as a set of Eclipse plug-ins that can be run in 3.3 or 3.4 versions of Eclipse.

Here is a minimalistic list of what is new:

General:

• Accessibility support
• Links in the help menu to forum and JRMC home page
• Better copy and paste support
• Extension points that let you extend JRockit Mission Control

JRMC Console:

• Updated MBean Browser
  • Can drill down into CompositeData, Tabular Data, Collections and Arrays directly in the attribute table tree
  • Configurable property key ordering for MBeans
  • Automatic updates on new MBeans being registered/unregistered
  • Information tab with MBean metadata
• Updated dials
  • Gradients
  • Formatting
  • Can add additional dials dynamically
• MBean Tree & Attribute Selector Dialog
  • Filters with wildcards
  • Improved performance
• Triggers
  • Import/Export of trigger rules
  • Triggers can be ordered in groups
  • Triggers can now have descriptions
  • Trigger templates for common use cases
• Attributes
  • Now shows per thread CPU usage
  • Total pause time for the last GC
• Tab groups / Category toolbar navigation
• New Diagnostic Commands tab

JVM Browser:

• A connection can now be tested before added to the JVM Browser tree
• User configurable application names

JRA:

• New recording templates
• Tab groups / Category toolbar navigation
• New overview tab that aggregate important information
• New system tab with JVM and OS-related information
• New recording tab with recording related information
• New allocation tab
• New code related overview tab
• New threads / locks overview tab
• New latency overview tab
• New latency thread tab 
• Histogram moved to new latency histogram tab
• Improved tooltips
• Configurable category toolbar

Here are a few screenshots:

There is also a set of neat experimental plug-ins that will be published as soon as we get the go ahead from legal. The first release of the Experimental Update-site will (at least) contain:

• PDE Wizards for creating plug-ins for JRockit Mission Control
• A JConsole Plug-in Plug-in which lets you run JConsole plug-ins inside JRockit Mission Control
  (It is, IMHO, a much better idea to convert them to true JRMC plug-ins though. ;) I just implemented that plug-in for fun.)

For more detailed information about the 3.1.0 release, please check out the “New and Noteworthy” page introduced with this release.

Using jrcmd there is a way to bring up the agent after the fact that JRockit has been started. See one of my previous blogs for more information on how to use jrcmd.

To use jrcmd  to start up the external management agent, you use the start_management_server command. Here is an example:

D:\clients\hirt>jrcmd 3848 start_management_server ssl=false authenticate=false port=4711

This command doesn't return any message upon successful completion, but on the console for process 3848 you should see:

[JRockit] Management server started on port 4711, ssl=false, authenticate=false.

The first way of getting your thread dump is to use jrcmd. My previous blog shows some basic jrcmd usage, so I'll just mention the command name: print_threads. Basic usage is jrcmd <PID> print_threads, for example jrcmd 780 print_threads.

The second way is to simply start the management console on the JRockit you want to monitor. After connecting the console to the JVM and switching to the threads view, you should be looking at something similar to the screen shot below.

The third way is to use the MBean Browser's capability to invoke arbitrary operations on MBeans (also described in the last blog). Go to the MBean Browser in the JRockit Management Console. Select the DiagnosticCommand MBean, and switch to the operations tab. Select the execute operation that takes a String argument and returns a String. Click the String button, and fill in the argument print_threads.

When you execute the operation you should see something like this:

There are also ways of doing this programmatically, for example by using the JRockit JMAPI, or by invoking the execute operation programmatically as described in another old blog.

There is fortunately a way to do exception profiling with JRockit today. There are exception related verbose flags available in JRockit. These are examples on how to use them:

java -Xverbose:exceptions=debug ...

java -Xverbose:exceptions=trace ...

For a list of valid verbose options, please see http://e-docs.bea.com/jrockit/jrdocs/refman/optionX.html#wp999543.

Sometimes you really just want to enable this profiling for a little while, for example to avoid cluttering your log files. Then there is a nifty tool for JRockit called jrcmd you can use to turn on/off the exception profiling. It can be found under JROCKIT_HOME\bin\.

First use jrcmd to list all running java processes. Here is an example of what it may look like:

>jrcmd

10984 jrockit.tools.jrcmd.JrCmd

9396 C:\Java\eclipse3.3.1.1\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v200
70828.jar -data D:\Data\workspaces\workspace_3.3_facade -os win32 -ws win32 -arc
h x86 -showsplash -launcher C:\Java\eclipse3.3.1.1\eclipse.exe -name Eclipse --l
auncher.library C:\Java\eclipse3.3.1.1\plugins\org.eclipse.equinox.launcher.win3
2.win32.x86_1.0.2.R331_v20071019\eclipse_1021.dll -startup C:\Java\eclipse3.3.1.
1\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar -exitdata 1908_7
c -vm D:\jrockits\R27.4.0_R27.4.0-90_1.5.0\bin\javaw.exe -vmargs -Xms256m -Xmx51
2m -XgcPrio:deterministic -XpauseTarget:40 -Dosgi.bundlefile.limit=100 -jar C:\J
ava\eclipse3.3.1.1\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar

10976 Gegga

The numbers are the PIDs of the processes, and are used as the first argument to jrcmd to specify on what JRockit to address. You can use jrcmd to check what commands are available. Here is an example:

>jrcmd 10976 help
10976:
The following commands are available:
        kill_rmp_server
        start_rmp_server
        kill_management_server
        start_management_server
        checkjrarecording
        stopjrarecording
        startjrarecording
        print_object_summary
        memleakserver
        print_codegenlist
        print_class_summary
        run_optfile
        dump_codelayout
        dump_codelist
        dump_codemap
        print_utf8pool
        print_properties
        print_threads
        datadump_request
        runsystemgc
        runfinalization
        heap_diagnostics
        oom_diagnostics
        print_exceptions
        version
        timestamp
        command_line
        memprof
        sanity
        verbosity
        set_filename
        help
        print_memusage
For more information about a specific command use 'help <command>'.
Parameters to commands are optional unless otherwise stated.

Let's get more information about the print_exceptions command:

>jrcmd 10976 help print_exceptions

10976:
Enable printing of Java exceptions thrown in the VM.
To turn exception printing off completely you need to set exceptions = false
even if it was turned on by stacktraces = true. NOTE: This handler is
deprecated. The preferred way of displaying exceptions is to use the
'exceptions' logging module: -Xverbose:exceptions.
Values for the parameters can be "true|all|false"
true  - print all exception except java/util/EmptyStackException,
java/lang/ClassNotFoundException and
java/security/PrivilegedActionException
all   - print all exception
false - don't print exceptions
        exceptions  - print exceptions (string, false)
        stacktraces - print stacktrace (string, false)

Never mind that it is using an old handler in R27.6. The functionality will be the same. Let's enable the exception profiling:

>jrcmd 10976 print_exceptions stacktraces=true

If your application is throwing exceptions, you should now be seeing traces being logged to the console of that application. To turn off the exception logging, we do as the help suggests:

>jrcmd 10976 print_exceptions exceptions=false

Now, an even easier way to access the jrockit diagnostic commands is to use the JRockit Management Console. Simply connect the JRockit Management Console to the JRockit you wish to enable exception profiling on (from JRockit Mission Control). (Click the images to look at them in full size.)

Once the console is started, open the MBean Browser tab and move to the DiagnosticCommand MBean under bea.jrockit.management:

Double clicking on the ArrayList value of AllCommands will open up a list of all the available commands:

 
Now, select the operations tab and the executeDefault method that takes a String argument and press invoke. This will provide you with a dialog with push buttons for the arguments. In this case a single button with the label String. Press the String button and fill out the command. For example, print_exceptions stacktraces=true.

Press Ok on both of the dialogs and exception profiling should now be enabled. To turn it off again, just invoke the operation again and enter print_exceptions exceptions=false, analogously with how you would use jrcmd.

An even easier way for Oracle employees is to pick up a recent internal build of JRockit and use the Diagnostic Command tab in the JRockit Management Console. :) Soon coming to a JRockit near you!

The preliminary schedule is as follows:

Date: 2008-09-21

Hands-On Lab: Diagnostics with Oracle JRockit Mission Control

Session ID: S299540
Track: Oracle Develop: Java
Room: Golden Gate B2
Start Time: 13:15

Date: 2008-09-22

Hands-On Lab: Diagnostics with Oracle JRockit Mission Control

Session ID: S299540
Track: Oracle Develop: Java
Room: Golden Gate B2
Start Time: 16:00

Date: 2008-09-23

Nonintrusive Profiling and Diagnostics with Oracle JRockit Mission Control

Session ID: S299518
Track: Oracle Develop: Java
Room: Nob Hill AB
Start Time: 13:00

Hands-On Lab: Diagnostics with Oracle JRockit Mission Control

Session ID: S299540
Track: Oracle Develop: Java
Room: Golden Gate B2
Start Time: 16:00

I'm looking forward to seeing you there! :)

The, in my humble opinion, greatest change is that all JRockit Mission Control features are available by default. There is no need to dabble with licenses. Everything is free to use for evaluation, which among other things means that you can now try out the latency analyzer properly.

JRockit Mission Control has also been relocated to a new homepage at OTN, located at http://www.oracle.com/technology/products/jrockit/missioncontrol/index.html. The next few days a lot of new JRockit Mission Control related material will be posted there.

The update site has moved as well, and can now be found at http://www.oracle.com/technology/software/products/jrockit/missioncontrol/updates/eclipse-3.3/jrmc/.

As you will undoubtedly notice, everything has also been re-branded.

Now, the cool new feature is actually a JRockit JVM side upgrade, that will be automatically picked up by the JRockit Mission Control client. It is now possible to do very cheap memory allocation profiling using the JRockit Latency Analyzer.

There is a new type of latency events available in the latency recordings. They are triggered whenever the JRockit JVM needs to acquire a new Thread Local Area or whenever the JRockit JVM needs to allocate a new large object. These events provides a good approximation to what is causing the most pressure on the memory system. This means that it is quite easy to find out where to start optimizing allocation behaviour using JRMC LAT.

Here is an example:

1. First select the JVM you wish to start a JRA recording on. 
   
   
2. In the JRA recording wizard, ensure that you start a JRA recording with latency information in it.
   You can for example use the Latency Recording Template. 
   
   
3. Then open the Latency Log tab and open a histogram over the events.
   Make the histogram over the Object Allocation - Class Name property by selecting it in the second combo box. 
     
   Note: since the allocation events aren't recognized yet as being from the standard producer, you may need to enable them in the event palette to the left.
   
   As you can see, most of the pressure on the memory system seems to be from the allocations of Strings. This is not uncommon. Together with arrays of primitive types, Strings are quite commonly high ranking here.
   
4. Now right click on the String row in the table, and set the operative set to the events corresponding to that row.
   The selected event property will unfortunately be reset, which will cause the histogram to be reset as well, but never mind that.
   
5. Move over to the Latency Traces view and check that you only want to see the events in the operative set. 
      You can now clearly see exactly where you should focus your efforts to reduce the amount of String allocation to reduce the pressure on the memory system.

Reducing the pressure on the memory system leads to less frequent garbage collections and thus a more responsive system.

For more information on the JRockit JVM R27.6 release, please have a look at the release notes.

Despite JRockit being an outspoken server side JVM, many long running client applications, like IDE's, actually run very well on JRockit. Running Eclipse on JRockit is no exception.

The easiest way to change the JVM on which to start Eclipse is by modifying the eclipse.ini file. You can also set the -vm on the command line used to start Eclipse. In windows you'd typically do that in the shortcut you use to launch Eclipse. Just using JRockit out of the box yields pretty good performance. Here is an example ini file:

-showsplash
org.eclipse.platform
-vm
D:\jrockits\R27.5.0_R27.5.0-111_1.5.0\bin\javaw.exe

You can usually get better performance by setting the initial heap size and the max heapsize to the same, thus bypassing the dynamic growing/shrinking of the heap:

-showsplash
org.eclipse.platform
-vm
D:\jrockits\R27.5.0_R27.5.0-110_1.5.0\bin\javaw.exe
-vmargs
-Xms384m
-Xmx384m

The insanely rich (or BEA employees) can run Eclipse on WLRT/deterministic GC (some would call this overkill) for a very smooth experience. This is the eclipse.ini I use myself:

-showsplash
org.eclipse.platform
-vm
D:\jrockits\R27.5.0_R27.5.0-110_1.5.0\bin\javaw.exe
-vmargs
-Xms384m
-Xmx384m
-XgcPrio:deterministic
-XpauseTarget:20
-XXcompactratio:1

One common pitfall is trying to use Sun specific flags, which would cause the JRockit launcher to exit right away, like for example -Xincgc or -Xbatch.

For more information:

• JRockit
• JRockit Mission Control

Mission Control available as Eclipse Plug-ins

For the first time we're making Mission Control available as a set of Eclipse Plug-ins! This means you will have the power of Mission Control readily available from within your IDE. It also means you will be able to update Mission Control from within the IDE.

The Eclipse integration comes with basic JDT integration, such as the ability to jump to source from stacktraces, classes and methods being displayed in Mission Control.

Running Mission Control within Eclipse requires a 3.3 version of Eclipse or above. Also note that, to get the most out of Mission Control running in Eclipse, you should run Eclipse on JRockit. More on interesting ways of doing that in an upcoming blog. :)

Mission Control Public Bugzilla

There is now a public bugzilla for Mission Control available at bugzilla.bea.com. It is monitored by the Mission Control developers and provides an efficient means for posting change requests and suggestions for enhancements.

Improved GUI

A lot of GUI changes have been made to make Mission Control play nice in an Eclipse environment. The menu layouts have changed. The JRA wizard has been improved greatly. JRA recordings can now be stored in an Eclipse project as a resource and launched by just double clicking (starting the default editor) on the resource. The memory consumption has been lowered and performance improved (yes, we doggy fed Mission Control to itself ;) ). Even more performance improvements will be available in the next major version of Mission Control.

You can now export charts from the Console as images. You can synchronize the charts X-ranges. You can add and remove charts from the Overview in the Console. You can, after freezing the updates of a chart, hover over data points to get exact readings. There are filters available to more easily find specific MBeans. And much, much more.

The Dial concept is back! Some of you may remember them from the old days of the Management Console. They are configurable and can show any attribute you want. And, if you do not like them, you can simply remove them altogether from the overview.

More Data

There is now more data available in Mission Control. In JRA we show the nursery size before and after a young space collection. We can record lazy unlocking profiling data. In the latency recorder we're recording more information in the events (for instance thread transition information for park/unpark).

Fixes

And we have of course fixed problems found, for instance Memleak not properly updating the trend table under certain conditions. Please see the release notes for further information.

Summary

There is a new Mission Control out with new features and better community support. Try it out and let us know what you think!

For more information:

• JRockit
• JRockit Mission Control

There are new options added to the JRA recordings almost every release. In recent releases of Mission Control the JRA wizard will check what capabilities the JRockit you are attempting to start a recording on has, and present you with configurable options accordingly. The problem is that the legacy protocol used when connecting to a 1.4 version of JRockit unfortunately does not support querying for the available parameters. Do not despair; there are still means of starting JRA recordings that contain all the new goodies. This is how:

There is a neat little command line tool called jrcmd that can be found in JROCKIT_HOME/bin. The jrcmd tool can be used to invoke commands on a locally running JRockit process. It works like this:

1. Do JROCKIT_HOME/bin/jrcmd to list the JRockit processes on your machine.
2. Pick your favourite one and do JROCKIT_HOME/bin/jrcmd <pid> help
3. Pick the command you wish to know more about, for example JROCKIT_HOME/bin/jrcmd <pid> help startjrarecording
4. Invoke the command with the settings of your choice.

In this case, the command we want to use is startjrarecording, and what we want to know is what parameters we can use on a particular JRockit when issuing the startjrarecording command.

On the windows box I'm currently on, it looks like this:

D:\jrockits\R27.3.0_R27.3.0-106_1.5.0>bin\jrcmd.exe
2640 com.jrockit.mc.rcp.start.MCMain

5012 jrockit.tools.jrcmd.JrCmd

Notice how it lists itself. In this case I'm interested in knowing the available commands on the JRockit currently running my Mission Control (com.jrockit.mc.rcp.start.MCMain), so I do:

D:\jrockits\R27.3.0_R27.3.0-106_1.5.0>bin\jrcmd.exe 2640 help
2640:
The following commands are available:
        kill_rmp_server
        start_rmp_server
        kill_management_server
        start_management_server
        checkjrarecording
        stopjrarecording
        startjrarecording
        print_object_summary
        memleakserver
        print_class_summary
        print_codegenlist
        run_optfile
        dump_codelayout
        dump_codelist
        dump_codemap
        print_utf8pool
        print_properties
        print_threads
        datadump_request
        runsystemgc
        runfinalization
        heap_diagnostics
        oom_diagnostics
        print_exceptions
        version
        timestamp
        command_line
        memprof
        sanity
        verbosity
        set_filename
        help
        print_memusage
For more information about a specific command use 'help '.
Parameters to commands are optional unless otherwise stated.

To find out what parameters are available to me when starting a jrarecording I do:

D:\jrockits\R27.3.0_R27.3.0-106_1.5.0>bin\jrcmd.exe 2640 help startjrarecording
2640:
Starts a JRA recording.
        filename           - name of the file to store JRA recording to
                             (string, jrarecording.xml)
        recordingtime      - length of the recording in seconds (int, 60)
        delay              - delay before starting recording in seconds (int,
                             0)
        methodsampling     - enable method sampling (bool, true)
        gcsampling         - enable gc information (bool, true)
        heapstats          - include heap statistics (bool, true)
        nativesamples      - include native code in sampling (bool, false)
        methodtraces       - include stack traces (bool, true)
        tracedepth         - depth of stack traces (int, 16)
        sampletime         - time between samples in milliseconds (int, 30)
        zip                - zip the recording (bool, true)
        hwsampling         - use hardware sampling if possible (bool, false)
        threaddump         - do full threaddumps at start and end of recordning
                             (bool, true)
        threaddumpinterval - also do threaddumps every 'n' interval (can be
                             specified as x[ns|ms|s]) (time, 0s)
        latency            - include latency analysis (bool, false)
        latencythreshold   - do not record events shorter than this number (can
                             be specified as x[ns|ms|s]) (time, 20ms)
        cpusamples         - sample cpu usage during the recording (bool,
                             true)
        cpusampleinterval  - cpu sample interval (can be specified as
                             x[ns|ms|s]) (time, 1s)

In this case I found out that I can indeed start up a recordings with new features such as latency analysis data on this particular JVM. To actually start such a recording I could for example write:

D:\jrockits\R27.3.0_R27.3.0-106_1.5.0>bin\jrcmd.exe 2640 startjrarecording laten
cy=true latencythreshold=20ms recordingtime=120s
2640:
JRA recording started.

The JRockit JVM incorporates technology (the JRockit Deterministic Garbage Collector) which can guarantee an upper bound for worst case pause times for garbage collections. This greatly helps in reducing unexpected latencies. When writing Java applications, however, it is still possible to introduce latencies through non-optimal use of Java Synchronization, I/O and so on. These latencies can cause poor performance and/or response times in your application and can be quite hard to find. The latency analyzer provides a simple way to analyze where such latencies are caused.

The JRockit Latency Analyzer is built into JRA (JRockit Runtime Analyzer) in Mission Control 3.0. When starting a JRA recording it is now possible to select a Latency Recording Profile. 

When such a profile is selected, or Enable Latency Recording is selected from the advanced options, the recorded profile will contain latency information. When a recording contains such information, three additional tabs (Latency Log, Latency Graph, Latency Traces), two views (Event Types, Properties) and a new Latency Perspective will be at your disposal.

The Latency Log tab includes a log which simply lists all the events in a table and lets you filter them. 

The Latency Graph tab includes a graph, showing for each thread which latency events that have happened during the duration of the recording.

The Latency Traces tab includes a tree table view showing you stack traces that have been involved in causing these latencies, and how much latency has been caused by the traces leading to a certain node.

In the example below we have found the response times of our latency sensitive application somewhat disappointing. The CPU isn't saturated, so we've decided to make a JRA recording with latency information in it. We're now viewing the recording in the latency graph (below). At the top of each view is the range selection tool, where you can zoom and pan to filter the events over time. I've zoomed in on an arbitrary part of the recording to show how the range selector looks when zoomed in. This particular recording shows the same problem all over the recording, so panning to another part would yield a very similar image.

From the graph we can see that we seem to do quite a lot Java Synchronization. In the log view (screen shot below) we can look at each of the individual events. In the screen shot I've filtered on the Java Synchronization Events and added the first bunch of them to the Operative Set. They are the ones highlighted in the Range Selector. Seems a good portion of them are indeed the Java Synchronization Events. Another way to select only the Java Synchronization Events would be to deselect the other Event Types in the Event Type view.

If we switch to the trace view, we can see that almost all the latency is caused from calls to a java.util.logging Logger.

Now, if we remove those logging calls, almost no Java Synchronization events remain, and thus the latency caused by those events have been eliminated. See below for a picture of a recording with the logging calls eliminated.

JRockit Mission Control 3.0 was recently made generally available. For more information about the features in Mission Control 3.0, please see the R27.3 release notes and the Mission Control Documentation.

For information about what was introduced with Mission Control 2.0, please see my previous blog entry - Mission Control 2.0 Sneak Peak

How to hunt for these memory leaks using the Memleak tool has been discussed to death, so this blog entry is going to show you other fun filled uses of the tool. ;)

First off we'll explore how Memleak can help us look at how any given type is being used within the JVM.

Start Mission Control and hook it up to a JRockit doing pretty much nothing but sleeping. In my case I'm connecting it to a JRockit started on my local machine.

You may want to pause the updating of the trend table by pressing the pause button in the toolbar above the table, especially if JRockit is very busy.

After pausing the updating of the table, locate a class for which you want to explore the dependencies, say Hashtable entries (java.util.Hashtable$Entry), and select Show Referring Types from the context menues to see what is pointing to that particular type.

You'll find that, not surprisingly, the entries are pointed to by hashtable entry arrays. Click the plus sign to work your way backwards, and you'll find out that, again not very surprisingly, various hashtable clones are pointing to these arrays. Click Hashtable to expand who is using Hashtables. Woooah!? We get a funny arrow directly to Hashtable from our Entry, thus completing a cycle in our graph.

Hmmm. Someone is obviously putting Hashtables into Hashtables. Now, who does that? Let's look at the instances that are taking part in that particular relationship. Bring up the context menu on the java.util.Hashtable$Entry, and select show instances. A dialog will pop up, prompting you to select for what relationship you want to list the instances. We select Hashtable, since we want to find out what entries that are pointing to hashtables. We get a list of entries, in my case 5 candidates.

As we can see, there are four of them keeping alive more than 100 000 bytes of data. Let's pick the top one - bring up the context menu and select to show who's pointing to that particular instance (Show Referring Instances).

Working our way backwards we see that it's the com.sun.jmx.mbeanserver.RepositorySupport holding on to a Hashtable that contains Hastables. We can now select the RepostiorySupport instance and verify that it indeed holds Hastables by bringing up the context menu and selecting "Inspect Instance".

Summary:

In this example we used the Memory Leak Detector in Mission Control for looking at relations between various types and instances in our running JVM. In this particular case we followed up on where people are putting hashtables into hashtables.

This is an updated version of my JRCMD goes remote blog entry. In version R27 JRockit had a major overhaul of the MBeans used to expose JRockit specific manageability features. One major difference is that the JRockit specific features are not loaded into the platform MBean server by default. To load them, a specific MBean must first be created, which in turn will load the rest of the MBeans exposing the API. The MBeans also moved to a new domain: "bea.jrockit.management".

The MBean to load is the bea.jrockit.management:JRockitConsole MBean. This can be done by simply using the MBeanServerConnection, for example like this:

MBeanServerConnection#createMBean(
   "bea.jrockit.management.JRockitConsole", null);

The following example is an altered version of my old "JRCMD Goes Remote" blog that, just like the JRCMD, allows the performance counters and ctrl-break handlers to be read/executed - but remotely from another machine.

import java.lang.management.ManagementFactory;
import java.net.MalformedURLException;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

import javax.management.Attribute;

import javax.management.InstanceNotFoundException;

import javax.management.MBeanAttributeInfo;

import javax.management.MBeanServerConnection;

import javax.management.ObjectName;

import javax.management.remote.JMXConnector;

import javax.management.remote.JMXConnectorFactory;

import javax.management.remote.JMXServiceURL;

/**

 * Simple code example on how to execute ctrl-break handlers remotely.

 * 

 * Usage: RemoteJRCMD -host  -port  -user  -pass 

 * -command  []

 * 

 * All arguments are optional. If no command is specified, all performance

 * counters and their current values are listed.

 * 

 * @author Marcus Hirt

 */

public class RemoteJRCMD {

  private final static String   KEY_CREDENTIALS                = "jmx.remote.credentials";

  private final static String   JROCKIT_PERFCOUNTER_MBEAN_NAME = "bea.jrockit.management:type=PerfCounters";

  private final static String   JROCKIT_CONSOLE_MBEAN_NAME     = "bea.jrockit.management:type=JRockitConsole";

  private final static String[] SIGNATURE                      = new String[] { "java.lang.String" };

  private final static String   DIAGNOSTIC_COMMAND_MBEAN_NAME = "bea.jrockit.management:type=DiagnosticCommand";



  public static void main(String[] args) throws Exception {

    HashMap commandMap = new HashMap();

    commandMap.put("-host", "localhost");

    commandMap.put("-port", "7091");

    for (int i = 0; i < args.length; i++) {

      if (args[i].startsWith("-")) {

        StringBuilder buf = new StringBuilder();

        int j = i + 1;

        while (j < args.length && !args[j].startsWith("-")) {

          buf.append(" ");

          buf.append(args[j++]);

        }

        commandMap.put(args[i], buf.toString().trim());

        i = j - 1;

      }

    }

    executeCommand((String) commandMap.get("-host"), Integer

        .parseInt(commandMap.get("-port")), commandMap.get("-user"), commandMap

        .get("-password"), commandMap.get("-command"));

  }

  public static void executeCommand(String host, int port, String user,

      String password, String command) throws Exception {

    MBeanServerConnection server = null;

    JMXConnector jmxc = null;

    Map map = null;

    if (user != null || password != null) {

      map = new HashMap();

      final String[] credentials = new String[2];

      credentials[0] = user;

      credentials[1] = password;

      map.put(KEY_CREDENTIALS, credentials);

    }

    // Use same convention as Sun. localhost:0 means "VM, monitor thyself!"

    if (host.equals("localhost") && port == 0) {

      server = ManagementFactory.getPlatformMBeanServer();

    } else {

      jmxc = JMXConnectorFactory.newJMXConnector(

          createConnectionURL(host, port), map);

      jmxc.connect();

      server = jmxc.getMBeanServerConnection();

    }

    System.out.println("Connected to " + host + ":" + port);

    try {

      server.getMBeanInfo(new ObjectName(JROCKIT_CONSOLE_MBEAN_NAME));

    } catch (InstanceNotFoundException e1) {

      server.createMBean("bea.jrockit.management.JRockitConsole", null);

    }

    if (command == null) {

      ObjectName perfCounterObjectName = new ObjectName(

          JROCKIT_PERFCOUNTER_MBEAN_NAME);

      System.out.println("Listing all counters...");

      MBeanAttributeInfo[] attributes = server.getMBeanInfo(

          perfCounterObjectName).getAttributes();

      System.out.println("Counter\tValue\n=======\t====");

      String[] attributeNames = new String[attributes.length];

      for (int i = 0; i < attributes.length; i++) {

        attributeNames[i] = attributes[i].getName();

      }

      Iterator valueIter = server.getAttributes(perfCounterObjectName,

          attributeNames).iterator();

      while (valueIter.hasNext()) {

        Attribute attr = (Attribute) valueIter.next();

        System.out.println(attr.getName() + "\t=\t" + attr.getValue());

      }

    } else {

      System.out

          .println("Invoking the ctrl-break command '" + command + "'...");

      ObjectName consoleObjectName = new ObjectName(DIAGNOSTIC_COMMAND_MBEAN_NAME);

      Object[] params = new Object[1];

      params[0] = command;

      System.out.println("The CtrlBreakCommand returned: \n"

          + server.invoke(consoleObjectName, "execute",

              params, SIGNATURE));

    }

    if (jmxc != null) {

      jmxc.close();

    }

  }

  private static JMXServiceURL createConnectionURL(String host, int port)

      throws MalformedURLException {

    return new JMXServiceURL("rmi", "", 0, "/jndi/rmi://" + host + ":" + port

        + "/jmxrmi");

  }

}

The following example would list all the performance counters and their values on localhost on the default port (7091):

java RemoteJRCMD

The following example would start a 60 second JRA recording on a JRockit running at the host bitsy, port 7099, writing the resulting recording to a file called nisse.zip:

java RemoteJRCMD -command jrarecording filename=nisse time=60 -host bitsy -port 7091

And as always, don't forget to enable the JMX management agent of the JRockit you wish to monitor. You can enable the management agent by using the -Xmanagement option like so:

-Xmanagement:port=7091,ssl=false,authenticate=false