Skip navigation
1 2 Previous Next


20 posts
Tomas Hurka and I gave a BOF last night presenting "Monitoring and Troubleshooting Java applications using JDK tools". The slides give an overview of the tools in the JDK, summarize the symptom and tools to use to diagnose a few typical performance problems including memory leak, deadlock, high lock contention that we walked through the demos. Check out the documentation, article and other resources listed in the slides that has detailed information. If you are using JDK 5 or 6 earlier to update 7, you can download Java VisualVM at  

JavaOne 2009 Blog

Posted by mandychung May 20, 2009
2009speaker.png This JavaOne I'll be speaking with Tomas Hurka, the VisualVMauthor on Wednesday June 03 at 6:45 p.m.: BOF-4724: Monitoring and Troubleshooting Java
Java VisualVM is a new JDK tool added since JDK 6 Update 7 (<JDK>/bin/jvisualvm). It provides a nice graphical user interface for monitoring and troubleshooting Java applications and integrates several troubleshooting features introduced in JDK 5 and 6 as command-line utilities into this single GUI tool. I like theirscreencast that shows VisualVM in action. It should help you get started. I also embed it here for your convenience:  See also the Java VisualVM User Guide: project page: the VisualVM team know what you think and any feature you'd like to see.  
Very soon, in a week or two, the Java compiler (javac), packaging tool (jam), and the Java module system implementation in the OpenJDK Modules project will support the new module keyword (the language support for JSR 277). The engineering team have built a special workaround to enable ourselves to build the Java module system while waiting for the language support. With the javac and jam tool support (thanks to Jonathan Gibbons and Kumar Srinivasan), you can now experience developing, building and packaging of a JAM module as JSR 277 spec defines. The language support for JSR 277 consists of two parts: module membership and module accessibility. The module accessibility support requires both the javac and JVM support which will go in next (stay tuned!). This blog is to help you get started to build and play with JAM modules using the JDK built from the Modules project with the module membership support. Module Membership DeclarationThere are two different ways to use the module keyword to declare module membership: 1) To declare module membership in the individual source file of a class (recommended): // hello/ module hello; package hello; public class HelloWorld {     .... } 2) To declare module membership in // hello/ module hello; package hello; Themodule hello; declaration in a source file of a class applies the module membership to that particular class whereas the same module declaration in will apply the module membership to all classes in the "hello" package. Compile a module Since the module keyword is a new feature, you will need to run javac with -source 7 option: $ javac -source 7 -target 7 hello/*.java Module Compilation Unit A file is used to express the version, import dependency as well as other metadata about the module using annotations (java.module.annotation.*). Following the convention of, could be stored in a directory corresponding to the module name. will be used by the jam tool to build a JAM module. For example, my hello.HelloWorld application depends on two libraries ( and that will be expressed in file as follows: // hello/ @Version("1.0") @ImportModules({     @ImportModule(name=""),     @ImportModule(name=""),     @ImportModule(name="") }) @MainClass("hello.HelloWorld") module hello; The@MainClass annotation specifies the main entry point of the application. You can download this sample aplication containing the hello,, and modules and try it out. Package a JAM Module The JDK provides a new JAM module packaging tool called "jam". To build the hello module:$ jam cf hello.jam hello/module-info.class hello/HelloWorld.class The jam command is similar to the jar command. The jam tool analyzes the list of input files and the module-info.class and generates the JAM module metadata (META-INF/MANIFEST.MF entry in the jam file). This metadata will be used by the Java Module System at runtime to enforce the versioning constraint and resolve the import dependency. To build the other two JAM modules provided in the sample application, $ jam cf com/foo/*.class $ jam cf com/bar/*.class Launch a Module Application Once you build the JAM modules, you can run the module application as follows: $ java -jam hello.jam The -jam option is similar to the -jar option but launching a JAM module. Another way to launch the application:$ java -repository . -module hello The -repository option specifies the source location of the JAM modules and the -module option specifies the module name containing the main entry point. Exercises There are few things you can try out: 
  • Modify to access FooOrderImpl. It should fail. FooOrderImpl is a package-private class which is not exported in the module and thus is not accessible outside its own module.
  • Add a new isPaid() method in the interface. Modify the sample application to use the new version as follows: 
    1. Modify to call the new Order.isPaid() method and print the value
    2. Modify to implement the new Order.isPaid() method
    3. Modify com/foo/ to a new version "2.0"
    4. Modify com/bar/ to a new version "2.0" and import with version="2.0+"
    5. Build the JAM files and
    Running java -jam hello.jam should continue to work with the new 2.0 version of those two libraries (i.e. printing out the value returned from the new isPaid() method).
  • Modify hello/ to specify the version of the imported modules as follows: // hello/ @Version("1.1") @ImportModules({     @ImportModule(name=""),     @ImportModule(name="", version="1.0"),     @ImportModule(name="", version="1.0") }) @MainClass("hello.HelloWorld") module hello; You can build a jam file called "hello-1.1.jam" and run it as: $ java -repository . -module hello:1.1 This should use the 1.0 version of the OrderProcessingService and the PrintService.
Let us know what you think. Feedback and Questions Please send your feedback and questions to We are working to post a JDK binary built from the Modules project once the module membership change is integrated (stay tuned).  
The draft specification for supporting OSGi bundles in the Java Module System is currently under discussion in the JSR 277 Expert Group. To enable the EG and the community to provide feedback, we have included an OSGi repository prototype in the OpenJDK Modules project. The prototype currently supports only Apache Felix OSGi implementation for proof-of-concept. There are open issues to be resolved. The out-of-the-box support is yet to be designed and implemented. Supporting other OSGi implementations is to be investigated. We hope that this prototype enables the community to begin participating and provide feedback for OSGi interoperability support. We are working on posting a JDK binary built from the modules-dev project to make it ready for you to try out and experiment the JAM modules development as well as the OSGi support. In the meantime, you can clone the source from the Modules mercurial repository and build the JDK. The OSGi repository for the Java Module System The OSGi repository is packaged as <JAVA_HOME>/lib/osgi-repo.jar. To build the JDK with the OSGi repository, do the following (refer to the OpenJDK build instructions for details): 
   gnumake OSGI_FRAMEWORK_JAR=<pathname of the jar file for the OSGi core API> \
           FELIX_JAR=<pathname of felix.jar> all images 
Note: We will remove the build dependency of the jar files for the OSGi core API and Felix in a future implementation.Setting up the OSGi repository The modules-dev implementation provides a repository configuration file (<JAVA_HOME>/lib/module/ to set up the repositories created at VM startup. To set up the OSGi repository: 
  1. Download the Apache Felix OSGi implementation.
  2. Uncomment the following lines in the and configure the "osgi.container" property to the pathname of felix.jar and the "osgi.source" property to the desired source location for OSGi bundles:
       osgi.container=file:///<URI of felix.jar>
       osgi.source=file:///<source location where OSGi bundles are loaded from>
You can either update the <JAVA_HOME>/lib/module/ or override the repository properties file by specifying this system property in the command line:<pathname of the file>
Known bug: The VM does not exit when the Felix container has been started unless System.exit() is explicitly. The OSGi repository starts the Felix container during initialization which started a non-daemon thread ("FelixDispatchQueue" thread). Since the FelixDispatchQueue thread is still running, the program will not terminate. OSGi Repository Initialization When the OSGi repository is being initialized during the VM initialization, it will first load the configuration properties file that is "conf/" under the parent directory of the directory where felix.jar is located; if it doesn't exist, the default configuration properties will be loaded. Then it will load and start the Felix OSGi framework specified in the "osgi.container" property. All bundles in the source location of the OSGi repository will be automatically installed and started as the OSGi repository initialization. To start Felix, the bundle cache profile name or directory is required to be specified to indicate where the installed bundles will be cached. If there is no set up, you can set this system property at VM startup: 
   -Djava.module.osgi.repository.cache=<bundle cache profile directory name>
Develop a JAM module to use an OSGi bundle A JAM module that imports an OSGi bundle expresses its dependency in the same way as importing a JAM module. For example, each JAM module has a file to express its module name, version, and its import dependency. 
// hello/
   @ImportModule(name="", version="[1.0, 3.0)"),
   @ImportModule(name="", version="2.0+")
module hello;
This "hello" module imports two modules, "" and "" and they are specified in the @ImportModule annotation regardless of whether they are OSGi bundles or JAM modules. Say "" is an OSGi bundle whereas "" is a JAM module. To successfully resolve the imports, we will need to configure the OSGi repository as an ancestor of the repository for the "hello" module. The source location of the OSGi repository is where the "" and other OSGi bundles are located. To launch this "hello" module application, it can be as simple as follows: 
   <JAVA_HOME>/bin/java< with osgi set up> \
       -Djava.module.osgi.repository.cache=cache \
       -jam hello.jam
You can refer to the documentation in the Modules project for how to create and launch a JAM module in details. Questions and Feedback Please send your questions and feedback to [Comment is closed for this blog because I will not be able to respond to any blog comment the next few weeks (on vacation).]  

JavaOne 2008 Blog

Posted by mandychung May 5, 2008
There are the Java Modularity session and BOF on Wednesday (5/7/2008)at JavaOne: TS-6185: Modularity in the Java  
A draft specification for supporting OSGi bundles in the Java Module System is put together based on the past EG discussion in particular the proposals and inputs from Glyn Normington, Richard Hall, and Bryan Atsatt. It is expected to evolve based on further inputs from the JSR 277 Expert Group. With the OSGi expertise from the JSR 277 EG and their contributions, we expect that this specification can be finalized soon. Your feedback is welcome and please send them to Just to highlight a few main points: 1. One or more module system implementations can run on a single Java virtual machine (e.g. JAM module system and OSGi module system). 2. A Java module can import an OSGi bundle. 3. OSGi bundles are exposed as ModuleDefinitions in the Java Module System. 4. Other module system can find OSGi bundles via the repository delegation model. 5. OSGi bundles are resolved by the OSGi module system using its own algorithm. One thing noteworthy:
JSR 277 defines the framework and API for the Java Module System and also defines the JAM module system as the default module system implementation for the Java SE platform and the JAM file format as its distribution format. JSR 277 Early Draft (EDR2) is being updated to clearly separate the distinction between the Java Module System framework and the JAM module system implementation. We recognized the issue with the JSR 277 EDR that didn't clearly separate the framework/abstraction from the JAM module system implementation that led to confusion and also skeptic about the OSGi interoperability support. Bryan Atsatt also identified and raised this concern to the EG. We hope that the EDR2 will be available in a few weeks after JavaOne. In the mean time, the draft spec includes some spec clarification relevant for this support. In addition, Bryan has a nice blog about JSR 277 interoperation that serves very well to set up the context ready for the coming discussion (thanks Bryan). I'd also like to blog more about this work but probably after JavaOne when I get some time.  
I recently take on a new challenge and join the JSR 277 project working on JSR 277 and OSGi interoperability. There are lots to learn and I am trying to come up to speed as quickly and effectively as I can. Thanks to all the interests and excitements around this topic! I appreciate in advance the participation and contribution from the JSR 277 and 291 Expert Groups and the OSGi experts. Our goal is to ensure that existing OSGi bundles can be used in Java SE 7. Like everywhere else, resource has always been tight. But we are revamping the effort to move forward quickly. Stay tuned and please be patient with this new member on board :) 

Although I won't have time to work on Java SE serviceability, monitoring and management technologies in the near future, I'd still like to meet with you all at JavaOne 2008 to talk about these areas. I highly recommend to check out VisualVM (the next generation of Java SE troubleshooting GUI tool) at the Java SE booth. Very cool!

Hope we can show a demo on using VisualVM to monitor and manage Java modules some time soon!

JDK product registration is one of the most significant featuresin the new Java SE 6u5 release. This provides the ability to register the JDK installations through Sun Connection. Registering the JDK is optional. We would like the JDK registration to provide mutual benefitsto both Sun and the developers. 

JDK Installation Experience

There is a change in the JDK installation flow for this feature.install.PNG The above is the new panel of the Windows installer at the end of JDK installation. When you click "Finish", the JDK Registration Login page will be opened in a browser. To complete JDK registration, you will need to login your existing Sun Developer Network (or other Sun online account). If you do not have an existing account, you can create one during the registration process. After you login and the JDK is registered, you will see a "Thank You" page.       
JDK Registration Login page
Thank You page
Offline JDK Registration Page
There is an offline JDK registration page located in the JDK install directory (<JDK>\register.html) along with two localized versions (Japanese and simplified Chinese) that allows you to register your JDK any time after installation. 

Technical Details

The registration process begins after the JDK installation completes where you get the last panel providing the information about JDK registration. When you click "Finish", the following happens: Step 1: Collect the product registration data about the installed JDK including: 
  • JDK service tag. See "What is a Service Tag" in my previous blog
  • System information including hostname, OS name, version and architecture.
The completed list of data being collected is described at the JDK Product Information page. In the next release, additional system information may be collected and the JDK Product Information page will be updated accordingly. Step 2: Post the JDK registration data to Sun Connection via https and the data will be temporarily stored in a Sun Connection server until the JDK is registered. The data will be purged after a short period of time after it is received from the HTTP POST and if the JDK is not registered. Step 3: Launch the default desktop browser and open the JDK Registration Login page. Each JDK registration has a unique identifier which will be passed as part of the URL parameters and the Sun Connection registration web application will use it to look up the registration data it receives from the HTTP POST in step 2. Thanks to the new java.awt.Desktop API added in Java SE 6 release which helps the implementation a lot. Known limitation: On Solaris and Linux, the JDK registration implementation is dependent on Gnome libraries. If those libraries are unavailable, the Desktop API is not supported and no browser will be opened. See the Swing Tutorial for details. Step 4: A new file, <JDK>/register.html, and its localized versions (register_ja.html and register_zh_CN.html) will be generated in the JDK install directory. We call this file as an offline JDK registration page which combines step 2 and step 3 in an HTML form. This offline JDK registration page can be used to register your JDK any time. You may see this page opened in the browser in step 3 if your system doesn't have internet connection or fails to post the registration data in step 2 for example due to the network or firewall configuration. Step 5: Once the browser is launched, the JDK installation process will finish and exit. At this point, the JDK is not registered until you login your Sun Developer Network account or other Sun online account. If you do not register, no data will be saved in Sun Connection database. 

JDK Registration and Service Tags

My previous blog gave an overview of the Service Tags technology. Service tag is a digital product identifier to enable product registration. JDK registration process generates a service tag for the JDK. The service tag information will then be uploaded to Sun Connection during registration. If the JDK is installed on a Service Tags enabled system (i.e. the Service Tags software has been installed on your system), the JDK service tag will be created in the service tag registry and the JDK will be discoverable with the Registration Manager client tool. 


JDK product registration is part of Sun's larger effort to support registration across its hardware and software products. NetBeans, Glassfish and many other Sun products also provide the ability to register the products. You can track and manage your registered products at Sun Inventory Channel. Sun Inventory Channel is one of the Sun Connection services and it is a free inventory management portal that provides a centralized repository to organize and manage your deployed products on your systems. Registering the JDK and other products will enable us to provide faster and efficient services and collaboration, for example: 
  • provide you more customized updates including new releases, security fixes, and news relevant to your deployed products.
  • inform you when a change in one version of a product on your system would have an impact on other products you have running (related to performance, compatibility or security, for example).
  • enable us to better test and optimize performance for your system.
  • effectively communicate our product or service offerings based on the software you have installed on your system.


Recently I have been working on a new Java SE project related to aSun Connection Technology called Service Tags. I'd like to give a short introduction of the Sun Service Tags technology that you may find various interesting ideas of leveraging it. 

Sun Service Tags

The Sun Service Tags enable automatic discovery of thetagged systems and softwares on your systems or a local network. The JDK and JRE 6 update 4 will become discoverable when installed on Solaris and Linux service tag enabled systems. The Sun Service Tags are not limited for Sun products. You can create the service tags for your own products (hardwares, softwares, or services) and leverage the discovery capability for your environment to use. Discoverable products areregisterable at Sun Connection Inventory Channel. I'll talk about the JDK product registration next in a couple of weeks. 

What is a Service Tag?

Sun Service Tag is a XML-based unique identifer of a product instance containing a set of basic information about the product instance on a system. Below represents a service tag of a JDK instance.                                                                         
instance_urnurn:st:16f1e569-c583-4190-85ab-42339d984449Unique identifier for the product instance
product_nameJava SE 6 Development KitProduct name
product_version1.6.0_04-eaProduct version
product_urnurn:uuid:b58ef9a8-5ae8-11db-a023-080020a9ed93Product identifier
product_parent_urnurn:uuid:fdc90b21-018d-4cab-b866-612c7c119ed3Product parent ID
product_parentJava Platform Standard Edition 6 (Java SE 6)Product parent name
product_defined_inst_idid=1.6.0_04-ea-b07 x86Product defined instance ID
product_vendorSun MicrosystemsProduct vendor
platform_archx86Targeted product architecture
sourceWindows JDK i586 installerSource of the product instance
containerglobalOS container (e.g. Zonename)

The product_urn field of Sun products is in this format "urn:uuid:" followed with a 32 character long UUID but is not required by Sun Service Tags. You can also embed additional information about a product besides the basic one in the product_defined_instance_id field.

Service Tag Enabled System

To enable service tags technology, you need to install the Service Tags Software that consists of: 
  • Service Tags (ST) Registry: A XML-based registry that contains all service tags on a system locating at/var/sadm/servicetag/registry/servicetag.xml on Solaris and Linux or c:\Program Files\Sun\servicetagon Windows (or [ProgramFilesFolder]\Sun\servicetag if you have a different folder for program files).
  • A stclient utility: A command-line utility to add, update, and remove a service tag from the ST registry.
  • ST discoverer and listener: Two network services facilitating auto discovery,

Create your own service tag

Once you enable Service Tags on your system, you can add a service tag for any hardware, software or anything else you want to be tagged. For example, I have created a service tag for Skype just as an example by using thestclient utility (I installed Skype on my laptop for making international calls to my mom in Hong Kong) . You can do it in an interactive mode or with the -a option. 
   c:\Program Files\Sun\servicetag>.\stclient
   > a
   Enter instance URN (optional):
   Enter product (e.g. Sun Web Server): Skype
   Enter version (e.g. 6.1): 3.6
   Enter product URN: A-unique-ID-for-Skype
   Enter product parent URN: A-unique-ID-for-its-parent
   Enter product parent (e.g. JES): Free software
   Enter product defined instance id:
   Enter product vendor (e.g. Sun): Skype
   Enter platform arch  (e.g. SPARC): x86
   Enter container (e.g. zone 0): global
   Enter source (e.g. genesis patch): SkypeSetup.exe
   Skype 3.6 added
   Product instance URN=urn:st:1f158110-de82-11dc-a0f1-000f1f14443e
   Press enter to continue
stclient will create an entry in ST registry containing the given information and it will assign a product instance URN if not specified. You can run the stclient -g -i command to get the service tag of a given product instance URN or stclient -x to view all service tags in the ST registry. Below is the XML entry in the ST registry I added for Skype. 
    <product_parent>Free software</product_parent>
    <timestamp>2008-02-19 00:32:16 GMT</timestamp>


To discover the tagged products on your system, you can start theRegistration Manager client tool (a Java web start application also available at ST discoverer and listener services allow the system to be discovered via the Registration Manager client tool. These network services only communicate the service tag information with the Registration Manager client tool and do not communicate with any other services on your system. These are the screenshots of the Registration Manager client tool looking up the tagged products on my laptop:      
regclient.PNG regclient.PNG
The first screenshot shows that you can configure the Registration Manager client tool to perform the discovery on a local subnet or one or more specified systems. Note that the Registration Manager performs no communication with Sun until you decide to perform the "registration" step. I will blog about product registration later. The second screenshot shows the list of tagged products on your system including my tagged Skype. Several Sun hardware and software products including JDK and NetBeans IDE are discoverable and more are being added over time. A service tag for the Windows OS is also created as part of the Service Tags software installation. 

Inventory Channel

Sun Connection Inventory Channel is a free offering from Sun that provides a centralized repository to organize the deployed products on your systems and report on them using the report generation tool. My next blog about JDK product registration will cover more about it. One of the most basic and difficult problems IT departments have today is to simply know what systems, softwares, and even services they have. Systems and softwares are installed by various team members at all times. Systems are shut down and new software is upgraded. Sun Service Tags and Inventory Channel give IT new tools to manage this complexity. For example, you can quickly determine what JDK and JRE instances (Java SE 6 update 4 and later releases) are installed on which systems in your environment. 

For More Information

A preview version of the VisualVM tool is now available to try out:
Screenshots from the VisualVM page:           
Overview of running Java application
Basic telemetry of running Java application
Overview of running Java application
Basic telemetry of running Java application
JavaOne is next week. Hope to meet you at our BOFs:  I will also be at the Pavilion at the following times. Please drop by our booth and chat. 
  • Tuesday at 11:15am-1:00pm at booth 940 (Java SE: Start with the Source!)
  • Tuesday at 1:00pm-3:00pm at booth 965 (Java SE: Performance & Diagnostics)
  • Thursday at 2:45pm-4:45pm at booth 965 (Java SE: Performance & Diagnostics)
Java SE 6 final release is now available! My colleagues and I have blogged about Java SE 6 monitoring, management and diagnosability features in the past 1-2 years. This presents an overview of the monitoring, management, and diagnosability features in Java SE 6 and also serves as a starting point for you to find the relevant blogs/articles/documentation. Enjoy!                                                                                                         
FeatureBrief DescriptionBlogs/Articles
Dynamic Attach CapabilityWith JDK 6, you no longer require to start your application with any special option to be attached by JDK 6 tools. The Attach API enables you to build your own tool to attach to a running JVM and load a Java or native agent.
Heap Dump and AnalysisJDK 6 significantly enhances the ability of diagnosing memory problem. The HotSpot VM provides the ability to request a heap dump on demand from the jmap tool as well as programmatically. A heap analysis tool (jhat) is added in JDK 6 to browse the heap dump snapshot you obtain (see below for details).
OutOfMemoryError DiagnosabilityJDK 6 provides a better support to diagnose OutOfMemoryError. This error now includes a stack trace where the allocation failed. Another useful improvement is the -XX:+HeapDumpOnOutOfMemoryError option which tells the HotSpot VM to generate a heap dump when an allocation from the java heap or the permanent generation cannot be satisfied. In addition, a new -XX:OnOutOfMemoryError=<command> option is added for you to specify a command that the HotSpot VM will invoke when the OutOfMemoryError is thrown.
DTraceon SolarisJDK 6 HotSpot VM provides the built-in dtrace probes. You can now use dtrace to trace the whole stack of any running Java application on Solaris 10. JDK 6 comes with the sample DTrace scripts for you to start with (under the <Solaris JDK6>/sample/dtrace directory).
Troubleshooting GuideJava SE Troubleshooting Guide, a very popular and useful documentation , has been updated to include troubleshooting information for JDK 6.
JDK Monitoring and Troubleshooting Tools
jconsole The major JConsole enhancements include dynamic attach capability, the plugin API support and various UI improvement. 

JConsole can attach to any running application which does not need to start with option. The new JConsole plugin API enables you to extend JConsole to add your own tab or custom UI for the application MBeans.

jhatA heap analysis tool, formerly HAT, is added in JDK 6 to browse a heap dump snapshot. It provides built-in queries to examine classes, instances, root set, heap histogram and objects pending for finalization. It also supports a built-in query language, OQL, to query the heap which is particular useful when searching on large number of objects.
jmapThe jmap -dump and -histo options are now supported on Windows. It provides a light weight mechanism to obtain a heap histogram and heap snapshot on all platforms.
jstackThe jstack tool is now supported on Windows. You can print Java stack traces and also detect deadlocks on all platforms. You can also use the new jstack -l option to print the list of owned java.util.concurrent locks.
jinfoThe jinfo tool adds a new -flag option to get and set an VM option. For example you can use jinfo to set HeapDumpOnOutOfMemoryError at runtime.
API Enhancements
Java Management Extensions (JMX)The important features of the JMX API in JDK 6 are MXBeans and Descriptors. MXBeans enable bundling of related values in a MBean without requiring special client configurations to handle to bundle. Descriptors provide you a convenient way to attach additional metadata to your MBeans.
java.lang.managementThe API has been enhanced for monitors andjava.util.concurrent locks monitoring. You can find the list of locks owned by a thread and also report which stack frame locked a monitor. It also provides a new method to obtain the system load average. In addition, a new HotSpotDiagnosticMXBean API provides the programmatic interface to obtain a heap dump and set a VM option.
java.lang.instrumentThe java.lang.instrument API has been enhanced to provide support for dynamic transformation of loaded classes, multiple agents and appending to class loader search.
JVM Tool InterfaceJVM TI has been enhanced to provide multiple agents support, better dynamic instrumentation, enhanced heap walking API, resource exhaustion notification, support for early return and monitor stack depth.
Java Platform Debugger Architecture (JPDA)JPDA has been enhanced to support heap walking functionality, force early return, view method arguments when not compiled with -g, process attach connector, monitor stack depth, and breakpoint on monitor locks/release.

Additional References:

1. Article: Monitoring and Managing Java SE 6 Platform Applications

2. Crash Course: Java SE Monitoring, Management and Troubleshooting

3. Java SE 6 Observability and Solaris OS

I recently wrote an article "Monitoring and Managing Java SE 6 Platform Applications". Alan, Sundar, Kelly and I have blogged about various JDK 6 enhancements in the monitoring, management, and diagnosability area. This article gives you an overview of the monitoring and management capabilities out of the box in JDK 6 and presents a short course how to diagnose several common Java SE problems including memory leaks, deadlocks, and synchronization issues with the use of the JDK tools.