Mandy Chung's Blog

J2SE Archives

OSGi Repository for Java Module System

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/repository.properties) 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 repository.properties 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.parent=user
      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/repository.properties or override the repository properties file by specifying this system property in the command line:

   -Djava.module.repository.properties.file=<pathname of the repositories.properties 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/config.properties" 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 config.properties 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 module-info.java file to express its module name, version, and its import dependency.

// hello/module-info.java
@Version("2.0")
@ImportModules({
   @ImportModule(name="java.se"),
   @ImportModule(name="com.foo.xml", version="[1.0, 3.0)"),
   @ImportModule(name="com.bar.parser", version="2.0+")
})
@MainClass("hello.Main");
module hello;

This "hello" module imports two modules, "com.foo.xml" and "com.bar.parser" and they are specified in the @ImportModule annotation regardless of whether they are OSGi bundles or JAM modules.

Say "com.foo.xml" is an OSGi bundle whereas "com.bar.parser" 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 "com.foo.xml" and other OSGi bundles are located.

To launch this "hello" module application, it can be as simple as follows:

   <JAVA_HOME>/bin/java -Djava.module.repository.properties.file=<repository.properties 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 modules-dev@openjdk.java.net.

[Comment is closed for this blog because I will not be able to respond to any blog comment the next few weeks (on vacation).]

Supporting OSGi Bundles in the Java Module System

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 jsr-277-comments@jcp.org.

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.

JSR 277 and OSGi interoperability

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 :)

Digress:
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!

New JDK Registration Capability in Java SE 6u5

JDK product registration is one of the most significant features in 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 benefits to both Sun and the developers.

JDK Installation Experience

There is a change in the JDK installation flow for this feature.

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.

Benefits

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.

References

• JDK Product Registration Information (Japanese version)
• Sun Connection
• Sun Inventory Channel
• Sun Service Tag FAQ

Sun Service Tags and Inventory Channel

Recently I have been working on a new Java SE project related to a Sun 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

Discoverable products are registerable 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.

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\servicetag on 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

   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.

  <service_tag>
    <instance_urn>urn:st:1f158110-de82-11dc-a0f1-000f1f14443e</instance_urn>
    <product_name>Skype</product_name>
    <product_version>3.6</product_version>
    <product_urn>A-unique-ID-for-Skype</product_urn>
    <product_parent>Free software</product_parent>
    <product_parent_urn>A-unique-ID-for-its-parent</product_parent_urn>
    <product_defined_inst_id></product_defined_inst_id>
    <product_vendor>Skype</product_vendor>
    <platform_arch>x86</platform_arch>
    <timestamp>2008-02-19 00:32:16 GMT</timestamp>
    <container>global</container>
    <source>SkypeSetup.exe</source>
    <installer_uid>0</installer_uid>
  </service_tag>

Discovery

To discover the tagged products on your system, you can start the Registration Manager client tool (a Java web start application also available at https://sunconnection.sun.com/inventory).

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:

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

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

• Sun Inventory
• Sun Service Tag FAQ
• The Sun Connection Inventory Channel in a Nutshell
• Registering Your Inventory in the Disconnected Mode

Java SE 6 Monitoring, Management, Diagnosability

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

JConsole will be supported in Mustang

Here are the slides of the JConsole BOF that Leif Samuelsson and Jean-Francois and I gave at JavaOne on May 18th. Enjoy!

Using JConsole to monitor and manage your application

JConsole was shipped in Tiger JDK as a demo and experimental tool. In Mustang, JConsole becomes a supported tool like the other JDK tools such as java and javac. From the engineering team's perspective, we have been making sure that jconsole is of high quality in the same way as a supported tool. The major effort to make JConsole as a supported tool is to provide accessibility support. Leif Samuelsson, the lead and the author of JConsole, has been putting time in improving JConsole accessibility. We expect more work to put in build 86 which should be available for download in 2 weeks. Try out the Mustang snapshot and send us feedback!

Meet you @ JavaOne 2006

I'll be at JavaOne 2006 tomorrow through Friday! It's a great opportunity to meet you all. If you'd like to chat about JConsole, VM monitoring and management, or Java SE serviceability/troubleshooting, come by:
o Java SE Performance & Diagnostic Booth on May 16 (Tue) at 10:30am-12:15pm
o JDK Community (Peabody) Booth #723 "Ask the Expert" area on May 18 (Thur) at 11:00am-12:00pm

I'll be at two BOFs on May 18 (Thur) from 9:30pm to 11:30pm in Moscone Center North Mtg Rm 121/122:
o BOF-0442 Using JConsole to monitor Your Application
o BOF-3051 Using the Tools in JDK 5 and the Java SE 6 Platform to Diagnose Problems and Monitor Applications

Many experts from Java SE will also be at the "Ask the Experts" area. Come chat with them!

Mustang JConsole

JavaOne 2006 Conference is coming up soon! Our BOF "Using JConsole to Monitor and Manage Your Application" is on May 18, 2006 at 10:30pm. The 9:30pm BOF (same room) is the JDK Tools BOF. The Java SE serviceability team will be there. It's late at night but hope to see you there. We're going to do a live demo of the Mustang JConsole at the JConsole BOF.

Below gives you a summary of the Mustang JConsole features. Let us know what you think.

JConsole Plugin Support

A new com.sun.tools.jconsole.JConsolePlugin API is added in Mustang. You can build your custom plugin to run with JConsole, for example, to add a new tab to access your application MBeans.

JTop is a JDK demo that shows the thread CPU usage of all threads running in the application. This demo is helpful to identify the threads that has high CPU consumption. It is updated to be used as a standalone GUI as well as a JConsole plugin. To run JConsole with the JTop plugin:

   <JDK6>/bin/jconsole -pluginpath <JDK6>/demo/management/JTop/JTop.jar

To build a JConsole plugin, it's very simple:

1. Create a subclass of JConsolePlugin class and implement the getTab method and also the newSwingWorker method. The getTab method returns the list of tabs to be added to JConsole or an empty list. The newSwingWorker method returns the SwingWorker to be responsible for the plugin's GUI update.

2. Create a file "META-INF/services/com.sun.tools.jconsole.JConsolePlugin" to contain the fully-qualified class name of the plugin class. JConsole uses the service-provider loading facility to look up and load the plugins. You can have multiple plugins - one entry per plugin.

Sundar added a new scripting demo to demonstrate the power of using scripting language with JMX technology and the out-of-the-box manageability. This scripting demo is built as a JConsole plugin. It adds a scripting shell tab in JConsole where you can access MBean attributes or operations using a scripting language. To try, run JConsole as follows:

<JDK6>/bin/jconsole -pluginpath <JDK6>/demo/scripting/jconsole-plugin/jconsole-plugin.jar

Check out the file <JDK6>/demo/scripting/jconsole-plugin/src/resources/jconsole.js for the javascript commands. A few commands for you to start with:

> memory=mbean("java.lang:type=Memory") # to get the MemoryMXBean
> memory.Verbose      # get the value of "Verbose" attribute
> memory.Verbose=true # set the "Verbose" attribute to true
> memory.gc()         # invoke the gc() operation

Dynamic Attach Capability

JConsole can now attach to any applications running on Mustang JDK even if it wasn't started with -Dcom.sun.management.jmxremote option. This dynamic attach capability uses the attach API that Alan Bateman added in Mustang which enables a tool like JConsole to load the management agent in the target VM dynamically. It's a very useful feature and makes JConsole and the out-of-the-box management easier.

UI Improvements

There are many UI improvements in Mustang JConsole. Just to highlight a few: (1) JConsole now is using the system look-and-feel on Windows and Gnome desktop. (2) The connection dialog has been improved for user experience and a new sheet dialog is designed for the progress bar. (3) The thread tab now has a new detect deadlock button that finds the deadlocks involved in object monitors and java.util.concurrent ownable synchronizers. See the blog about "Thread dump and concurrent locks".

Overview Tab and VM Summary Tab

A new overview tab is added in Mustang JConsole to plot multiple charts in one tab to provide an easy way for users to correlate various resource consumption. Previously you would have to switch among several tabs if you want to correlate the data such as memory usage, threads, and CPU usage. Another improvement is that we merge the Summary tab and VM tab into one single "VM Summary" tab where you can cut-and-paste the selected text into a report file.

JMX MBean Metadata and Descriptor

JMX Descriptor provides a convenient way to add additional metadata to your MBeans. Mustang JMX supports descriptors for all types of MBeans. Eamonn's blog describes an easy way to add descriptors to your MBeans. Mustang JConsole makes the MBean metadata and descriptor information visible in the MBean tab.

HotSpot Diagnostic MBean

Mustang adds a HotSpot Diagnostic MBean (see com.sun.management.HotSpotDiagnosticMBean) which provides an API to request heap dump at runtime and also change the setting of certain VM options. You can access the HotSpot Diagnostic MBean via JConsole MBean tab. See Sundar's blog about setting VM options and my blog about diagnosing memory problems.

Try the latest version of Mustang JConsole and send us feedback!

From Monitoring to Diagnosing Memory Problem in Mustang

Mustang Beta Release is now available!

Mustang has several enhancements in the VM and the JDK tools to help identify the symptoms and diagnose memory problems. One typical type of memory problems is memory leak causing continuously growing in heap memory usage. Eventually it may lead to OutOfMemoryError. Another typical type is the application's performance problem with excessive object creation and deletion causing long pause garbage collections. In the past, you would typically restart your application to turn on -verbose:gc option to get GC verbose tracing to determine the time GC spent and the memory usage trend. Tiger monitoring and management support enables you to continuously monitor your application at production time and catches the symptom early on. Mustang brings more...

A few techniques Mustang provides:

1. Use jconsole to watch the memory usage of your application

The memory usage graph would clearly show if the memory usage is growing over time. It also provides the low memory detection support such that you can set a threshold to catch abormal behavior. For example, I set the memory usage threshold to 6 MBytes in the Tenured Gen memory pool. The amount of memory exceeding the threshold will be flagged in red color.

2. Use jconsole to monitor the garbage collection activities

The bottom panel of the memory tab displays the garbage collection statistics including the time it spent on GC and also the total number of collections happened. It would give you a rough idea of how frequent GC happens and how long the GC takes. If you want to turn on the verbose GC tracing to get details about individual GC invocation, you can do it dynamically through JConsole as described in the "Using JConsole to monitor applications" article. You don't need to restart your application.

3. Use jconsole to find out the number of objects pending for finalization

Finalizers would be one possible cause of memory leak. There is no guarantee when a finalizer will be run and whether it will be run at all. An object that has a finalizer will not be garbage collected until its finalizer is run. JConsole shows the number of objects pending for finalization in the summary tab which would be one useful information you may want to check when you suspect a leak.

4. Obtain heap histogram to help determine the leak suspect

jmap -histo will print the histogram of the heap showing the number of instances and the amount of memory of each class. jmap -histo option was extended to support on Windows in Mustang b67. The heap histogram would give you more information to determine if a memory leak would possibly exist. Often the class with growing number of instances could be one potential leak suspect.

5. Obtain heap dump snapshots and use jhat for heap analysis

Mustang enables you to get heap dump programmatically, at runtime using jmap and jconsole, at OutOfMemoryError and also from a core file. Mustang now also includes HAT (Heap Analysis Tool) as jhat utility. Check out several blogs about Mustang heap dump and jhat:

• Heap dump is back
• Heap dump snapshot
• Query Java heap with OQL

6. Prepare for OutOfMemoryError

Alan's blog describes the improvement in OutOfMemoryError and also a new VM option -XX:+HeapDumpOnOutOfMemoryError to tell the HotSpot VM to generate a heap dump when it runs out of memory. You can either specify the VM option at startup time or at runtime via jconsole's MBeans tab.

HotSpotDiagnostic MBean provides several diagnostic operations such as to dump heap and set VM option. We plan to provide a better UI for accessing the HotSpot diagnostic features.

In summary, the diagnosability of memory problem has been improved. Download Mustang beta or the latest Mustang snapshot and let you know your feedback.

Thread Dump and Concurrency Locks

Thread dumps are very useful for diagnosing synchronization related problems such as deadlocks on object monitors. Ctrl-\ on Solaris/Linux or Ctrl-Break on Windows has been a common way to get a thread dump of a running application. On Solaris or Linux, you can send a QUIT signal to the target application. The target application in both cases prints a thread dump to the standard output and also detects if there is any deadlock involving object monitors.

jstack, a new troubleshooting utility introduced in Tiger (J2SE 5.0), provides another way to obtain a thread dump of an application. Alan Bateman has a nice blog about jstack and its several improvements in Mustang (Java SE 6). Mustang jstack works like a remote Ctrl-\ or Ctrl-Break if you are on Windows.

jconsole is JMX-complaint GUI tool which allows you to get a thread dump on the fly. The "Using JConsole to Monitor Applications" article gives you an overview of the Tiger monitoring and management functionality.

Mustang extends the thread dump, jstack, and jconsole to support java.util.concurrent.locks to improve its diagnosability. For example, the Threads tab in the Mustang jconsole now shows which synchronizer a thread is waiting to acquire when the thread is blocked to lock a ReentrantLock and also which thread is owning that lock.

In addition, it has a new "detect deadlock" button (in the bottom). When you click on the "detect deadlock" button, it will send a request to the target application to perform the deadlock detection operation. If the target application is running on Mustang, it finds deadlocks involving both object monitors as well as the java.util.concurrent.locks. If the target application is running on Tiger, it finds deadlocks involving object monitors only. Each deadlock cycle will be displayed in a separate Deadlock tab.

Click here to see a wider form of this screenshot.

JDK 6 has a nice demo FullThreadDump under $JDK_HOME/demo/management/FullThreadDump where JDK_HOME is the location of your JDK 6. This demo has been included in JDK 5.0 and is updated to use the new Mustang API. It demonstrates the use of the java.lang.management API to get the thread dump and detect deadlock programmatically.

This work is licensed under a Creative Commons License.