|
|
Oracle JRockit Mission Control 3.1.0 is a further improvement of the JRockit Mission Control tools platform built on Eclipse Rich Client Platform (RCP) technology. These release notes contain important details about the latest enhancements and capabilities found in JRockit Mission Control 3.1.0. It contains information on the following subjects:
Oracle JRockit R27.6.3 supports these versions of the Jave JDK:
JRockit Mission Control 3.1.0 contains a large number of new features that will provide more information more seamlessly and improve the overall user experience. This section describes those features in the following subsections:
General enhancements to JRockit Mission Control provide:
The Management Console, the JRockit Runtime Analyzer and the JVM Browser can be navigated by the keyboard and custom widgets in Mission Control, like graphs and pie charts, now provides information for screen readers. Graphs and dials in the Management Console can also be rendered as tables by changing accessibility options in Preference dialog box. For more information, please refer to Accessibility Notes for JRockit Mission Control Client at:
http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/tools/intro/accessibility.htmlTo help the user to find further assistance and information about Mission Control the help menu now contains links to the Mission Control Forum and Home Page .
Copy and Paste now works for all tables and trees in the Management Console, the JRockit Runtime Analyzer and for the Properties View. Settings for turning column headers on/off and for indenting columns when copying trees have been added.
New features in the JRockit Management Console include:
The MBean Browser can now drill infinitely deep down into MBean attributes consisting of CompositeData, TabularData, Collections and arrays (Figure 2-2).
The dials on the Overview Tab (Figure 2-3) show the current and maximum value. You can configure the background gradient and how values are formatted and add new dials to the dashboard.
The MBean Tree (Figure 2-4) and the Attribute Selector dialog box can be filtered using a wildcard expression.
You can now import and export trigger rules from and to the local file system, either by using the import/export wizard (Figure 2-5) in the file menu or by clicking on the import/export button on the Triggers Tab.
Settings have been added for configuring how MBean names should be presented in the MBean Browser Tree (Figure 2-6).
The total pause time for the last garbage collection can be viewed in the Memory Tab (Figure 2-7).
The MBean Tree is refreshed when a new MBean is registered or unregistered on the monitored MBeanServer. You can turn on or off automatic refresh of the tree by using a toolbar button on top of the MBean Tree (Figure 2-8).
The Threads Tab shows how much CPU a thread uses as a percentage of the total CPU usage on all cores (Figure 2-9).
The Triggers Tab now contains a set of default rules that can serve as templates when creating triggers for JRockit or WebLogic 10.3 (Figure 2-10.
When you create a new trigger, you can now add a description and format the text by using the <B>, <LI> and <BR>-tags (Figure 2-11).
The MBean Browser Tab now shows MBean metadata (Figure 2-12).
The tabs in the Management Console have been split into four groups: General, MBean, Runtime and Advanced and a toolbar (Figure 2-13) has been added so you can navigate between the different groups. Tabs that have been added using the Mission Control tab extension point will be put in a fifth group called Other.
The Management Console has a tab called Diagnostic Commands (Figure 2-14) that allows power users to execute Ctrl-break handlers from a remote machine over JMX.
The Memory Tab contains a toolbar button for triggering a full garbage collection on the JVM that is being monitored (Figure 2-15).
New feaures in he JVM Browser include:
In the New Connection Wizard you can test a connection—to ensure that host name, port, password, and so on, are correct—before adding it to JVM Browser Tree (Figure 2-16).
You can now, by using a set of naming rules, give discovered Java-applications human readable names in the JVM Browser (Figure 2-17).
The Local Connection Provider Naming Rules create names for the JVM browser that are easier to read. These rules make it easy to find the JVM running Mission Control in 3.1.0.
A naming rule consist of two parts: a match part and a formatting part. The rules are tried in order, top to bottom. Whenever a rule’s match expression is fulfilled, the rule is formatted according to the formatting part of the rule.
The matching is done by first expanding the expression on the left of the equivalence sign and the expression on the right of the equivalence sign. The system then attempts to match them.
For example (see Table 2-1 and Table 2-2 for descriptions of the variables in these examples):
<PID> = <ThisPID> => This Mission Control (<PID>)
This rule will match any process that has the same process identifier (PID) as the process running the JRockit Mission Control instance. The result will be "This Mission Control (4711)" (if the PID is 4711).
<PID> <IsDebug> = <ThisPID> true => JRMC Running on Debug JRockit
This rule will match if the process is the one running the JRockit Mission Control Client and if it is running on a debug build of the JVM.
For more examples of rules, see the preconfigured rules in JRockit Mission Control Client.
Table 2-1 lists variables you can use on either side of the naming rule expression.
Table 2-2 lists variables that can only be used in the formatting part of the expression.
New features in the JRA include:
The JRA-recording wizard features four new templates:
You can select the necessary template from the Select recroding template drop-down list (Figure 2-18).
The tabs in the Runtime Analyzer have been split into six groups: General, Memory, Code, Threads/Locks, Latency and Other and a toolbar (Figure 2-19) has been added so you can navigate between the different groups.
There is a new overview tab that presents the most relevant data for the whole recording graphically (Figure 2-20).
There is a new overview tab for code related information that shows which packages and classes the application spent the most time executing (Figure 2-21).
There is a new System Tab that shows JVM and OS-related information (Figure 2-22).
There is a new Recording Tab that shows the start time of the recording and the recording parameters that were used(Figure 2-23).
The GC General tab has been renamed to GC Statistics and it contains more detailed information about garbage collection pauses and garbage collections. (Figure 2-24).
There is a new tab that shows thread local area (TLA) information and the ratio between the number of bytes allocated by small and large objects in the application. It's also now possible to see how much memory each thread has allocated during the recording (Figure 2-25).
There is a new overview tab showing information about threads, locks and CPU usage(Figure 2-26).
There is a new tab that shows the threads that were running during the recording (Figure 2-27).
There is a new overview tab displaying latencies categorized by type. The tab also shows which Java locks the application were blocked on the most (Figure 2-28).
There is a new tab that shows the total and average latency per thread (Figure 2-29).
The Event Value Histogram folder in the Latency Log Tab has moved to separate tab called the Histogram Tab and a details part, that shows the traces for all events that have a certain event value, has been added. This can be useful when trying to find out where in the application there has been contention on a lock (Figure 2-30).
Occupied Heap, that shows the amount of memory after a garbage collection, has been added to GC Event Tab (Figure 2-31).
The tooltip for a thread in the Latency Graph now shows start and end time for the thread, the thread id and the total allocation rate (Figure 2-32).
The tooltips for pie charts displays more detailed information about each slice (Figure 2-33).
The position of tab navigator can now be configured by the user (Figure 2-34).
New features in JRockit Mission Control’s Eclipse version include:
There are now extension points that allow third parties to extends the Management Console with tabs, trigger rules and triggers actions (Figure 2-35.
Eclipse wizards for creating classes that can use the new extension points exposed by JRockit Mission Control have been added (Figure 2-36).
The RJMX-API, which is an extension of JMX that Mission Control uses to subscribe to JMX-data and to establish connections to local/remote servers, is now open for public use. The API also includes classes that allow communication with JRockit JDK 1.4, which relies on a JRockit specific protocol instead of JMX. Accompanying the RJMX-API are two Eclipse-plug-ins which exposes API-functionality that can be used to extend Mission Control and create dials, tables and charts similar to the ones found in Mission Control today.
Earlier versions of JRockit Mission Control include many new and useful features. These new features and changes to earlier versions of this product are described in these sections:
JRockit Mission Control 3.0.3 is a maintenance release and contains no new features. For a description of the changes in this release, please refer to Changes in JRockit Mission Control 3.0.3.
The JRockit Mission Control Client is now available as an Eclipse plug-in edition. The plug-in version of the JRockit Mission Control Client provides seamless integration of JRockit Mission Control’s application profiling and monitoring toolset with the Eclipse development platform. By integrating JRockit Mission Control with Eclipse, you will have easy access to the powerful toolset that comprises JRockit Mission Control.
When the JRockit Mission Control Client is run within the Eclipse IDE, you have access to IDE features that aren’t otherwise available in the toolset when it is run as a standalone Rich Client Platform (RCP) application. The most significant of these features is the ability to see specific code in the running application by opening it directly from the JRockit Mission Control Client, a function called Jump-to-Source.
The other benefit of integrating the JRockit Mission Control Client with the Eclipse IDE is that it allows you to profile and monitor an application during its development phase just as you would during its production phase. This allows you to spot potential runtime problems before you actually deploy your application to production; for example, you might, while monitoring an application during its development notice a memory leak. By catching the memory leak during development, you can correct it before you migrate your application to a production environment.
For more information, please see Integration with the Eclipse IDE or open the JRockit Mission Control Client and launch the help system.
The location of the Eclipse update site will be published at
http://dev2dev.bea.com/jrockit/tools.html when available.
JROCKIT_HOME/missioncontrol/samples/jrarecordings/. The files are:pricing_server_logging_on.jrapricing_server_logging_off.jrajava2d_demo.jra| Note: | This file is a recording of the demo located at JROCKIT_HOME/demo/jfc/Java2D. The Java2D demo folder contains the source, allowing this recording to demonstrate Jump-to-Source (Jump-to-Source is only available when you are running JRockit Mission Control within Eclipse, as described in Eclipse Integration of JRockit Mission Control 3.0.2). |
| Note: | This feature is only available when the graph is frozen. |
A latency analyzer has been added to the JRA. You can create recordings that contain latency information for your application. The JRA Tool now contains three additional tabs that all show latency data from different perspectives. These tabs are prefixed Latency and named: Latency Log, Latency Graph, and Latency Traces (Figure 2-40). Together with these three tabs, there are two auxiliary tabs that allow you to turn on and off event types on the latency tabs and view properties.
All tabs prefixed with Latency share a common Latency Timeline slide bar where you can easily zoom in and out of your JRA recording to find latency events within a specific time frame.
The new latency analyzer in the JRA Tool includes the following:
| Note: | For older versions of JRockit Mission Control you will need a license file to use the Latency Analyzer. You can purchase the license from Oracle. |
The JRA recording wizard now contains three templates that will make it easier to setup your JRA recording. The templates are the following:
In addition to the new Latency Analyzer recording capabilities, other recording capabilities have been added to the JRA: thread dumps and CPU load can be specified under the advanced options when creating a JRA recording. You can also set the interval for each sample type (Figure 2-42).
The JRA also records lazy unlocking statistics as part of lock profiling. For more information on lazy unlocking, see -XXlazyUnlocking in the Oracle JRockit JDK Command-Line Reference.
In JRockit Mission Control 3.1.0 it is possible to record thread dump data in the JRA and then view thread dumps in the newly added Threads tab in the JRA Tool (Figure 2-43).
JRockit Mission Control 3.1.0 is now available in a Japanese version (Figure 2-44) and a simplified Chinese version (Figure 2-45).
The English user documentation for JRockit Mission Control 3.1.0 will be translated after the general availability release to Japanese and Simplified Chinese. Please refer to the Japanese and Chinese eDocs sites for more information.
For the JRockit Mission Control 3.1.0 release, the user documentation is available as online help within the tool itself and on eDocs as PDFs, see http://edocs.bea.com/jrockit/tools/index.html.
This section describes the changes and issues resolved in all versions of JRockit Mission Control from 3.0.0 to 3.1.0.
Table 2-3 lists changes in JRockit Mission Control 3.1.0
Table 2-4 lists changes in JRockit Mission Control 3.0.3.
When viewing the GCs tab of a JRA recording, the legend for the References and finalizers chart has been changed. The label Objects with finalizers (formerly Final references) shows the total number of existing objects having a finalizer. The label Finalization queue length (formerly Objects with finalizers) shows the total number of objects waiting on finalization after a collection.
|
|||
When trying to run the Eclipse version of JRockit Mission Control with Sun Hotspot JDK6_5, some users were unable to create a new connection and the connector panel showed only a few, if any, JDP connectors. This has been fixed.
|
|||
A tooltip has been added to the Latency Time Line (the graph at the top in a LAT recording) that shows activity at a specific point on the timeline (Figure 2-46).
|
|||
When expanding references in the Memory Leak Detector’s instance graph, almost every object node seemed to be referenced by a Global JNI Handle. Also, occasionally, objects would be referenced by the thread root
(Memleak Socket Reader). This issue would clutter the graph with false dependencies, making it difficult to follow the actual reference chain and find the leak. This has been fixed.
|
Table 2-5 lists changes in this version of JRockit Mission Control.
Table 2-6 Changes in JRockit Mission Control 3.0.1lists changes in this version of JRockit Mission Control.
Table 2-7 lists changes in this version of JRockit Mission Control.
Table 2-8 lists issues known to exist in JRockit Mission Control 3.0.0 through 3.1.0.
Local JVMs might disappear from the JVM browser if the naming rules have been changed in the Local Preferences window (accessed from the Window menu by selecting Preferences > JRockit Mission Control > Browser Preferences > Local Preferences. If a rule is modified and does not follow the (undocumented) syntax in certain ways, and then applied, the thread that discover the local JVMs dies.
|
|
In the dialog box used for entering a master password to encrypt JMX passwords, all text is missing. Corrected, it should appear as shown below:
|
|
Java applications running a 1.4 JVM will appear in the Discovered/Local folder in the JVM browser, prefixed with
[1.4]. When trying to connect to one of these you will get an error message because local attach isn't supported in 1.4; however, this error message omits this important information: to connect to this JVM you should start the JVM with
-Xmanagementlocalhost:7090. You also need to select the JDK 1.4 radio button in the Connection Wizard’s Host JDK-version group.
|
|
If you try to start the Memory Leak Detector with a 32-bit JRockit Mission Control on a 64-bit JVM, you will receive an error message but it will not contain any information about JVM being 64-bit. Instead, the error message generated when you try to connect to the Console or start a JRA recording will contain this information.
|
|
In the version of JRockit Mission Control that shipped with the JRockit JDK R27.4 the value shown in Heap Usage Before for a garbage collection in a JRA recording is incorrect. The value shown is actually the value of Heap Usage After for the proceeding collection. This will be fixed in the version of JRockit Mission Control that ships with JRockit JDK R27.5.
|
|
When starting a JRA recording from JRockit Mission Control, you can cause incorrect time values if you edit the time before selecting the recording type. This usually happens when you switch back and forth between seconds and minutes. If you set the number of seconds to less than a minute you can lose your settings and the time value will become zero.
|
|
When attempting to save a graph as an image on Linux systems (accessible from the graph context menu), the file dialog box might lack a filename input text field and the OK button might not respond. If this is the case, saving the graph as a
.png file will not work, and pressing Cancel is your only option.
|
|
When JRockit Mission Control shipped with the JRockit JDK R27.1 is run with a Japanese or Traditional Chinese locale on an installation of Windows where the system font does not in itself contain glyphs for that language (such as in English editions of Windows, by default), bold fonts in the Memory Leak Detector will be incorrectly rendered as boxes. This will be fixed in the JRockit Mission Control shipped with the JRockit JDK R27.5.
|
|
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.
|
|
If the default Windows temporary directory (
java.io.temp) is on a FAT file system, some tools will not be able to discover local processes. These tools include JRockit Mission Control, jrcmd and jconsole.
For security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports setting permissions on files and directories (for example, on an NTFS file system). It is not supported on a FAT file system that provides insufficient access controls.
|
|
In some rare cases, you might get a Script Debugger error when launching the Online Help in JRockit Mission Control on Windows. This can occur if you have deselected the option Browsing>Disable script debugging (Other) in Internet Explorer and have a script debugger installed. If you click No when prompted, everything will work as designed.
|
|
In a JRA recording, the number of allocated TLA (Thread Local Areas) is recorded, as well as the preferred size of a TLA (in bytes). The JRA GUI will multiply these values to get the number of bytes allocated in TLAs during the entire recording; however, the size of the TLAs actually used can sometimes be a bit smaller than the reported size (the preferred size is only a preferred size; fragmentation can cause the TLAs to become smaller) and the value printed in the GUI can be overestimated.
|
|
Currently, if you are running JRockit Mission Control on a 1.4 version of the JRockit JVM shipped with the JRockit JDK R27.1, you cannot use the JRA Recording Wizard to start JRA Recordings with latency data. RMP (the legacy management protocol) does not currently provide information about the recording capabilities of a JRockit JVM instance.
|
|
If JRockit Mission Control is started on RHEL4 using the
bin/jrmc executable, the online help may not work. Instead of opening the help browser, a dialog saying “Couldn’t open help on {0}” is shown.
Instructions can be found at http://www.eclipse.org/swt/faq.php#browserlinux.
This problem is also described at
http://www.eclipse.org/swt/faq.php#browserlinuxrcp
|
|
When looking at predecessors in the Methods tab of the JRA Tool, sometimes the percentage can become lower, even though the nodes are not branching. This is caused by stack depth not being high enough for some of the samples participating in calls leading through the method being looked at. You can avoid this by increasing the Trace Depth in the JRA Recording Wizard.
|
|
