Oracle JRockit Mission Control 2.0 and 2.0.1 Release Notes
Oracle JRockit Mission Control 2.0.1 is the new JRockit JVM tools platform built on Eclipse Rich Client Platform (RCP) technology. These release notes contain important details about the latest enhancements and capabilities found in this and previous releases. It contains information on the following subjects:
Features and Enhancements in JRockit Mission Control 2.0.1
JRockit Mission Control 2.0.1 is a maintenance release, which means that no major features have been added. The most noticeable improvements are the following:
In the General Information panel on the General tab of the JRA, you can now see when the JRockit JVM process started and how long thereafter the JRA recording started (in the Uptime before recording field).
Figure 3-1 shows the new fields JRockit start time and Uptime before recording field on the General tab in the JRA Tool.
Figure 3-1 The JRockit JVM start time and uptime before recording
List of Running Processes
There is a new Processes tab in the JRA Tool (Figure 3-2). This tab gives you a snapshot of all processes running on the machine at the start and end of the recording (marked 1 in Figure 3-2). If you click on a process, you will see all its details (marked 2 in Figure 3-2).
Note:
The command line information is not available for recordings made on Windows.
Figure 3-2 The new Processes tab in JRA Tool
Time Information About Optimization
On the Optimizations tab in the JRA Tool (Figure 3-3), you can now see when an optimization of a method started (in the Start Time column), when it ended (in the End Time column), and how long it lasted (in the Time column).
Figure 3-3 The Optimizations tab in JRA Tool
Improved Visualization of Garbage Collections
The pause times generated by old-generation garbage collections (Old Collections—OC) and nursery garbage collections (Young Collections—YC) are represented more clearly in the JRA Tool (Figure 3-4).
Figure 3-4 Old Collections and Young Collections in JRA Tool
Features and Enhancements in JRockit Mission Control 2.0
For the release of JRockit Mission Control 2.0, there have been several major improvements to the tools. The most noticeable improvements are the following:
The user interface is now built on the Eclipse Rich Client Platform, which means that menus, mouse and keyboard behavior, the help system, etc. will be familiar to you if you are used to the Eclipse IDE.
All the familiar tools from the first version of JRockit Mission Control, have been merged into one unified GUI (see Figure 3-5) with the addition of a JRockit Browser that simplifies finding and connecting to running Java applications. It even allows you to monitor several applications simultaneously. Figure 3-5 shows the new and integrated version of all available tools in JRockit Mission Control 2.0.
Figure 3-5 The JRockit Mission Control with all Applications Open
JRockit Mission Control 2.0 consists of the following parts:
JRockit Browser: the latest addition to the tools suite. A new way to locate a JRockit JVM instance and by selecting it start monitoring through the Management Console or the Memory Leak Detector.
Historical Data: a low overhead way to keep track of attributes and to see trends for attributes. You can select attributes from JRockit JVM, your own applications, or any other application that has MBeans registered on the MBean Server.
JRockit Runtime Analyzer: the popular runtime analyzer tool with several new additions: more data is recorded, filtering functionality in graphs, context sensitive help, and more.
Memory Leak Detector: the great way to spot memory leaks within your application. This tool is now included as part of JRockit Mission Control 2.0.
Management Console: the most widely used JRockit Mission Control tool that allows you to monitor live data from the JRockit JVM. This tool allows you to monitor the running Java application, create triggers that notify you when a predefined condition is met and much more.
Usability Enhancements
This release contains a large set of usability enhancements, for example:
Drag and drop functionality.
Documentation is now available from the Help menu. For the JRA tool, the help is context sensitive, which helps you analyze the immense amount of data available.
Possibility to manipulate views freely, which for instance allows you to compare profiling records next to each other.
Interfaces have been localized in Japanese. Use jrmc -nl ja_JP to set JRockit Mission Control to Japanese.
Additional Diagnostics Data
More detailed diagnostics data is now available in the JRA tool, in particular, more detailed GC information.
Connect on Demand
JRockit Mission Control 2.0, will automatically detect and be able to connect to the JRockit JVM (5.0 and later) instances on the local machine, as long as the JRockit JVM and JRockit Mission Control has been started by the same user.
For remote monitoring, the JRockit JVM includes the multicast-based JRockit Discovery Protocol (JDP), which allows JRockit Mission Control to automatically discover running instances of the JRockit JVM. When this is enabled, a automatically generated list of all discovered JRockit JVMs will appear in the JRockit Browser.
To enable JDP, start the JRockit JVM with -Xmanagement:autodiscovery=true, see -Xmanagement.
Most Recent Changes
The following has been fixed in the JRockit Mission Control 2.0 for the different release:
Changes in the JRockit Mission Control 2.0.1 Release
The following has changed in the JRockit Mission Control 2.0 release.
Change Request ID
Description
CR311881
The total number of context switches per second was calculated incorrectly on Linux. This has now been fixed.
The number of context switches per second is presented in the System total #context switches/second field in the Threads panel on the General tab of the JRA Tool.
CR309660
In Oracle JRockit JDK R27.1 changing CPU affinity did not work for 1.4 versions of the JRockit JVM. It now works for all JDK levels.
CR307277
In JRockit Management Console, the Freeze scrolling check box is automatically selected when you zoom in on a graph by right-clicking and selecting Zoom in on the Zoom menu. Previously, this only happened when you zoomed in on a selection of the graph (by right-clicking and selecting Selection on the Zoom menu).
CR307277
Passwords were not stored properly from the JRockit Connection window in the JRockit Browser (when the Store password in settings file (clear text) check box was selected). This issue has now been fixed.
CR305851
The suggested port in the Connection Wizard for the Oracle JRockit JVM 1.4.2 is now 7090, that is, the default port for the RMP protocol used by the Oracle JRockit JVM 1.4.2. In JRockit Mission Control 2.0, the port had to be set manually to 7090 since the Connection Wizard suggested 7091 (the default port for the JMX protocol).
CR304563
Only file paths valid on the machine running JRockit Mission Control were allowed for JRA recordings (see Known Issues, CR304566). This has now been fixed.
CR303923
JMXMAPI did not properly support changing the garbage collection strategy by changing the strategy attribute of the bea.jrockit.management.GarbageCollectorMBean
This has now been fixed.
Note:
The strategy changes when the next garbage collection occurs. You can force a garbage collection with the gc operation of the GarbageCollectorMBean after changing the strategy attribute.
CR303920
In the JRockit JVM included in JDK 5.0, attempting to start the management server on a port that was in use resulted in an exit from the JVM (see Known Issues, CR303920).
This has now been fixed.
CR302945
The Compaction Ratio displayed in the Old Collections section on the GC Events tab in JRockit Runtime Analyzer (JRA) is now calculated correctly. The actual number of available compaction parts is always used in the calculation.
Previously, the default number of available compaction parts was instead used in the calculation, sometimes resulting in an incorrect ratio.
CR302733
In the Management Console, you can edit the titles of graphs and axes. To do this, right-click on a graph and select the Edit titles submenu. On the submenu, select whether to edit the graph title, the X-axis title or the Y-axis title.
When you have changed a title, the new title is stored and will be used when you open the Management Console again.
CR302635
It should not be possible to create, rename or delete folder nodes under the Discovery folder but these operations were enabled in JRockit Mission Control 2.0 (see Known Issues, CR302635). This has been fixed in JRockit Mission Control 2.0.1.
CR302571
Previously, in JRockit Mission Control 2.0, there were some limitations on the handling of JRA files (see Known Issues, CR302571) that have been fixed in JRockit Mission Control 2.0.1.
Spaces can now be included in the name of a JRA file, and temporary recordings are always placed in the default temp directory (as specified by the system property java.io.tmpdir).
Note that if you use jrcmd on Windows, then a filename that includes spaces must be surrounded by \". For example:
jrcmd 3964 jrarecording time=100 filename=\"name with spaces.jra\"
CR301366
Previously, in JRockit Mission Control 2.0, if the startup parameters of a monitored JRockit JVM had changed since the first time a JRockit JVM was monitored, then no longer available attributes were still shown (but without any data) in graphs and other places in the Management console.
In JRockit Mission Control 2.0.1, attributes no longer available are greyed out in the Management Console.
CR293482
Before JRockit Mission Control 2.0.1, if the preferences had been changed to run the Memory Leak Detector in a JRockit Mission Control tab on Linux, then when the Trend or Allocation Stack Traces tab was open, the Detector's GUI flickered every time there was an update. This problem has now been fixed in 2.0.1.
Changes in the JRockit Mission Control 2.0 Release
The following has changed in the JRockit Mission Control 2.0 release.
Change Request ID
Description
CR292969
The JRockit Mission Control launcher on Linux, jrmc, has the following command-line options:
-nl—sets the locale, for example, jrmc -nl ja_JP for Japan and Japanese. The default locale is English. The argument to -nl, should follow the same format as return values from java.util.Locale.toString().
-help—displays the available options.
-version—displays version information of the JRockit JVM and JRockit Mission Control.
The JRockit Mission Control launcher on Windows, jrmc.exe, has the same options as its Linux counterpart. However, since it uses the “windows” subsystem (and not the “console” subsystem), the output is lost unless it is redirected. If run from a command shell, a way to redirect is to type “jrmc -version |more”.
CR293818
If you are running JRockit Mission Control on a Windows system, you need to be a member of the Administrators or the Performance Logs user groups to be able to create a JRA recording. The typical error message, for not being part of either of these groups, can look like this:
[perf ] Failed to init virtual size counter:
CR295172
The JRockit Mission Control 2.0 GUI is now available in the Windows Start menu.
CR298174
Before, any notification trigger in the Management Console, could be ignored the first time it arrived. This problem has now been fixed.
Known Issues
The following issues are known in the JRockit Mission Control 2.0 and 2.0.1 releases:
Issue
Description
CR355590
In the instance graph of the Memory Leak Detector, false references from a Global JNI Handle might be shown. Any such reference where the tooltip says “Number of handles:1” might be false. Similarly, but less frequently, references from a Threadroot:(MemLeak Socket Reader) are always false. These references are temporary references used in the implementation of the Memory Leak Detector in JRockit Mission Control. They do not keep objects alive.
CR315538
When doing a JRockit Runtime Analyzer recording, one of the pauses in concurrent garbage collections may increase slightly. The pause is normally in the 5 milliseconds range but during the JRA recording, the pause time may increase to around 10 milliseconds. Once the recording is completed, the pause time returns to normal.
CR310655
If you connect the JRockit Memory Leak Detector to the JRockit JVM running the Detector, then the JRockit JVM may run out of memory due to an object allocation feedback loop. You can alleviate this problem by refraining from inspecting stack traces or type graphs of commonly allocated object types, such as java.lang.String objects or char arrays.
CR313460
If you successively expand a method in the Predecessors panel on the Methods tab in the JRockit Runtime Analyzer, the percent value of the predecessors may start to decrease even if you do not reach a branching point. The percent value should stay the same as long as you do not expand to a branching point. This may happen both in JRockit Mission Control 2.0 and 2.0.1.
CR302355
On Linux, the problem with running the Memory Leak Detector in a tab of the main window with JDK 5.0 has been resolved in JRockit Mission Control 2.0.1. However, with JDK 6, there are other SWT/AWT interoperability problems due to AWT changes. As a consequence, the preference setting for how to run the Memory Leak Detector is now kept separately for each JDK version on Linux, and will only default to run in a tab on JDK 5.0.
CR307929
The Method Profiler in the JRockit Management Console currently only profiles the first matching class. There is currently no way to profile all matching classes, or a class specific to a certain class loader.
CR311881
On Linux, the value in the System total #context switches/second field is 1000 times too low. The field is found in the Threads panel on the General tab of the JRockit Runtime Analyzer. Note that this has been fixed in JRockit Mission Control 2.0.1.
Workaround:
Manually multiply the value presented in the System total #context switches/second field by 1000 to get the correct value.
CR293482
If the Memory Leak Detector is run in a JRockit Mission Control tab on Linux with the Trend or Allocation Stack Traces tab open, then the Detector's GUI flickers every time there is an update. Note that this problem has been fixed in JRockit Mission Control 2.0.1.
Workaround:
Always open the Memory Leak Detector in a separate window on Linux. This is the default on affected platforms.
CR289236
In the Management Console, the attributes available to graphs and in other places depend on startup parameters of the monitored JRockit JVMs. If the startup parameters of a monitored JRockit JVM has changed since the first time that JRockit JVM was monitored, attributes that no longer are available may still be shown, but without any data. Other than the missing data, there is no indication that the attributes are inactive.
Note that this problem has been fixed in JRockit Mission Control 2.0.1, where no longer available attributes are greyed out.
CR300410
There is a known problem with dark matter analysis in JRA recordings. No dark matter is calculated during the JRA recording. This is a problem on the server side, i.e. not the JRA tool itself.
Workaround:
Set -XXminblocksize on the command line of the JRockit JVM to be analyzed, i.e. before you start your application. The value should be set to the minimum TLA size used on that JRockit JVM The default is 2k.
CR301546
When clicking in the JRockit Mission Control MBeanBrowser, a java.util.ConcurrentModificationException might be printed in the JRockit Mission Control log file. This should not affect functionality in any way.
CR302355
Default for JRockit Mission Control 2.0 and Linux is to run the Memory Leak Detector in a separate window, instead of in a tab in the main window. For the JDK 1.4.2 on Linux, this is also the only way to run the Memory Leak Detector.
For other JDKs, it may be possible to run the Memory Leak Detector in a tab by changing preferences, but GUI updates may cause flickering in various degrees depending on the X server. This is due to SWT/AWT interoperability issues on X11.
In JRockit Mission Control 2.0.1 on Linux, the Memory Leak Detector can be run flawlessly in a tab with JDK 5.0, but not with JDK 6. The preference settings and defaults have been updated accordingly.
CR302571
There are some limitations on the handling of JRA files, depending how the recordings were started:
If started from jrcmd, no spaces are allowed in the given file name or path.
If started from JRockit Mission Control on an Oracle JRockit JVM 5.0 or higher, temporary recordings with names starting in jrockit and ending in .jra or .jra.zip are placed in the current working directory of the recording JVM and may be left in that directory even after a successful transfer to JRockit Mission Control.
Note that these limitations have been removed in JRockit Mission Control 2.0.1.
CR302635
It is possible to create, rename, and delete folder nodes under the Discovery folder. Note that this has been fixed in JRockit Mission Control 2.0.1.
Workaround:
Do not perform these operations on these nodes. If any of these operations is mistakenly performed on these nodes, you can simply restart JRockit Mission Control and everything will be back to normal.
CR303343
The Compaction Ratio displayed in the Old Collections section on the GC Events tab in JRockit Runtime Analyzer (JRA) is not calculated correctly. This happens if the number of available compaction parts is not equal to the default value of 128. Note that this has been fixed in JRockit Mission Control 2.0.1.
Workaround:
Calculate the correct value by dividing # Compacted Parts by Available Compaction Parts.
CR303920
In JRockit JVM 5.0, attempting to start the management server on a port that is in use, will exit the JVM (with System.exit(1)). This is especially dangerous if the management server is started using jrcmd, on a JRockit JVM that already is running. Note that this has been fixed in JRockit Mission Control 2.0.1.
Workaround:
Start the management server on JRockit JVM startup with the -Xmanagement option (including parameters).
or
Connect using local attach on the same machine, with JRockit Mission Control.
CR304566
If you are running JRockit Mission Control locally and want to create a JRA recording for a 1.4.2 JRockit JVM on a remote machine, you might run into a “Could not open JRA for <JVM connection>” problem. This problem occurs since the JRockit Mission Control GUI itself, only validates local file names when starting a JRA recording; whereas the 1.4.2 JRockit JVM on the remote machine, do not support the automatic transfer of JRA data to your local JRockit Mission Control. This issue has been fixed in JRockit Mission Control 2.0.1.
Workaround:
Use relative file names for your JRA recordings. These file names are interpreted relative to the current working directory of the recording JRockit JVM.
CR304936
When connecting to a JRockit JVM from the Management Browser in JRockit Mission Control, the Disconnect button and context menu items are disabled until something else is selected in the Management Browser and the connected JRockit JVM is reselected.
CR305851
The suggested port in the Connection Wizard for a JRockit JVM 1.4.2 is 7091. This is the default port for the JMX communication, but a JRockit JVM 1.4.2 doesn’t use the JMX-protocol. This means that the suggested port needs to be 7090, which is the default port for the used RMP protocol. This issue has been fixed in JRockit Mission Control 2.0.1, where the suggested port for a JRockit JVM 1.4.2 is 7090.
Workaround:
Set the port manually in the connection wizard to port 7090.
