Writing the JRockit book has made me take trips down memory lane more than once. The last read through made me think of one of the more embarrassing bugs we’ve had in JRockit Mission Control. Since it’s too late to add content to the book – most of the chapters are already finalized, or in the process of being finalized -  I thought I’d just put it here on the blog. 🙂

So, one of the more embarrassing bugs in Mission Control would be when an attibute was misspelt in the Management Console. An attribute ending with the word count lacked the letter ‘o‘. The bug report stated that the "customer was not amused".

I couldn’t help being slightly amused though.

The next major release of JRockit is finally out! Here are some highlights:

• Includes the all new JRockit Flight Recorder – supersedes the old JRockit Runtime Analyser. The new flight recorder is inspired by the “black box” in airplanes. It uses a highly efficient recording engine and thread local buffers to capture data about the runtime and the application running in the JVM. It can be configured to always be on, so that whenever anything “interesting” happens, data can be dumped for some time back. Think of it as your own personal profiling time machine.
• Automatic shortest path calculation in Memleak – no longer any need for running around in circles when trying to find your way back to a thread root from an instance.
• Memleak can now show class loader related information and split graphs on a per class loader basis.
• More easily configured JMX agent – default port for both RMI Registry and RMI Server can be configured, and is by default the same, allowing easier configuration of firewalls.
• Up to 64 GB (was 4GB) compressed references.
• Per thread allocation profiling in the Management Console.
• Native Memory Tracking – it is now possible to track native memory allocations with very high resolution. The information can either be accessed using JRCMD, or the dedicated Native Memory Tracking experimental plug-in for the Management Console (alas only available for the upcoming 4.0.1 release).
• JRockit can now produce heap dumps in HPROF format.
• Cooperative suspension – JRockit is no longer using system signals for stopping threads, which could lead to hangs if signals were lost or blocked (for example bad NFS shares). Now threads check periodically to see if they are suspended.
• VPAT/Section 508 compliant JRMC – greatly improved keyboard navigation and screen reader support.

See New and Noteworthy for more information.

JRockit Mission Control 4.0.0 can be downloaded from here:
http://www.oracle.com/technology/software/products/jrockit/index.html

I recently got tired of monitoring the weather for various locations to find a nice time and spot to fly my planes. Enter WindBot. WindBot sends me an e-mail whenever new opportunities are found:

—–

The WindBot@hirt.se has found changes to the available flying opportunities for you in Trollbäcken:

New opportunities:
==================
Friday 15:00 (2010-04-23) [wind 2.0m/s, precipitation 0.0mm, cloud cover 43.0%]
Friday 22:00 (2010-04-23) [wind 2.0m/s, precipitation 0.0mm, cloud cover 100.0%]

Lost opportunities:
===================

Triggering condition was:
MicroPlaneFlyCondition [wind speed <= 2.0, precipitation <= 1.0, 5 <= time <= 22]

/WindBot v0.0.3

—–

Lovely! 🙂

There are a bunch of JRockit related sessions at OOW 2009! Joy!

Here are the ones I am involved in:

Other exciting sessions:

Here are a few links regarding new SPECjbb and SPECpower benchmarks with JRockit:

http://www.oracle.com/us/corporate/press/018046_EN 

http://www.oracle.com/us/corporate/press/018045_EN

http://www.oracle.com/us/corporate/press/018043_EN

http://www.oracle.com/us/corporate/press/018044_EN

Yay!

There is now an Oracle JRockit fan page on facebook! Either search for Oracle JRockit among the pages or go to:

http://www.facebook.com/pages/Oracle-JRockit/41075602577

I just added logos and other graphics from the ancient Appeal days. Ahhh, the memories…

Sometimes it may seem hard to get a simple thread stack dump from your JRockit. You may for instance have started it using the -Xnohup (-Xrs) option, or as a service. I’ll list three different ways of looking at your threads in such situations.

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.

Exception profiling is the business of finding out what exceptions are being thrown within your application and from where. In JRockit Mission Control you can find out how many exceptions have been thrown using JRA, and you can count the exceptions using the JRockit Management Console. Sadly there is no way of doing powerful exception profiling (i.e. looking at the stack traces for the exceptions, aggregating them and visualizing them directly in the JRockit Mission Control Client) just yet. This will be incorporated in a future version of Mission Control.

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!