Sun's Chuk-Munn-Lee Troubleshoots Java SE 6
By Janice J. Heiss on Mar 05, 2008
It was so neat to meet Chuk in person, as I interviewed him in July of 2005 for java.sun.com. He has programmed in Java since 1996, when he first joined Sun in Hong Kong. He currently works as a senior developer consultant and technology evangelist for Technology Outreach at Sun in Singapore. Chuk's focus is: Java APIs, Java EE, Java SE, and Java ME. He has worked with key Asia-Pacific independent software vendors (ISVs) during the last six years to help them design, prototype, develop, tune, size, and benchmark their Java applications. Chuk appears quite at home in Australia, having graduated in 1987 from the Royal Melbourne Institute of Technology in Melbourne.
I remembered that Chuk is also an avid gamer and was experimenting with game creation in his spare time back in ‘05. It’s clear from his session that he loves to have fun, which is not unusual for developers. In my experience the stereotype of the nerdy developer just doesn’t hold up – developers are usually charming and fun, though it may be that their idea of fun is out of reach for some people.
Another observation and then I'll get on with the session - I promise. This is my first developer event outside of the U.S. In many ways, it could have been a small JavaOne judging by the look, manner, and even dress of the developers. Has code become the universal language?... :)
Chuk began the session by reviewing JVM improvements in Java SE 6 and referenced Mandy Chung’s blog which I strongly recommend if you want more details.
With JDK 6:
\* You are no longer required 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.
\* Memory problems are easier to diagnose. The HotSpot VM enables you to request a heap dump on demand from the jmap tool. A heap analysis tool (jhat) was added in JDK 6 to browse the heap dump snapshot you obtain.
\* It’s easier to diagnose OutOfMemoryError thanks to a stack trace where the allocation failed. Also the new -XX:+HeapDumpOnOutOfMemoryError option 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, enabling developers to specify a command that the HotSpot VM will invoke when the OutOfMemoryError is thrown.
\* The JDK 6 HotSpot VM provides built-in DTrace probes which means developers can now trace the whole stack of any running Java application on Solaris 10.
In addition the Java SE Troubleshooting Guide, has been updated to include troubleshooting information for JDK 6.
After briefly reviewing the basics of garbage collection, Chuk turned to the JDK tools, starting with the Java equivalent of Unix PS, lps, which is typically the first stop in diagnosing troubles. It lists the running VMs, including embedded ones, gives them a process number, the name of the application or class, and will dig down to differing levels of detail with command lines.
The second stop is jinfo which extracts information from the VM or core file. It will list configuration information from a running VM or a core file that includes VM properties and command line flags.
Third, jstat displays potentially detailed performance statistics for the JVM.
jstack provides the stack traces of all the threads attached to a virtual machine. It also will perform deadlock detection and will do a stack trace if the VM is hung.
jmap prints memory-related statistics, provides the details of the overall memory configuration with detailed info on space capacities – what and how much is free or used.
Chuk pointed out that HPROF has been around a very long time. It collects information on CPU usages, heap dumps and thread states. It uses the JVMTI interface to gain heap dump info. He showed how to use HPROF and explained that in running HPROF, it will only dump out the information after you exit the application, which can be gotten in text or binaries.
jhat (Java Heap Analysis Tool) allows you to interactively work with a memory snapshot captured by jmap, HPROF, or jconsole. jmap and HPROF collect the same information that jhat analyzes. jhat is much faster than HPROF and goes into the VM and extracts information from it directly, bypassing standard interfaces. HPROF can take a much longer time to provide information.
jhat has a set of pre-defined queries to show all the classes, objects and instances, reachable from the root set. Chuk insisted that when tracking down memory, do not look at the classes – look at instances. He recalled his first experience using jhat when he looked at the classes and was unable to identify the problem area.
When you start jhat standard queries operate. jhat enables developers to run custom queries with relatively easy functionality. Chuk offered one warning: On a big chip, if you are running a complex query – make sure you have a fast machine, or you may be in for a long wait.
He moved to the visual tool, jconsole, which is bundled with the JDK and offers a graphical console that enables developers to monitor and manage Java apps. An API enables developers to create their own plugins. jconsole provides info on:
\* Memory usage and GC activities
\* Threads, thread stack trace, locks
\* Objects pending finalization
\* Runtime information such as uptime, CPU time
\* JVM information such as classpath, properties, command line arguments, etc.
He mentioned another visual tool – visualvm, an open source project that is rumored to be headed for inclusion in the JDK. Chuk pointed out that for a long time people have used the NetBeans debugger to identify memory problems. The visualvm project has taken up that element of NetBeans and made it a standalone that looks better than jconsole, with a plugin architecture, and has the NetBeans window functionality. It runs only on JDK 6 and later. The idea is to encourage developers to develop their own tools as applications grow in sophistication.
“Standard tools will only take you so far,” remarked Chuk. This seems to be the wave of the future: application tools that enable you to fine tune with greater detail and specificity.
The rest of the session focused on common problems, primarily related to insufficient memory.
In watching Chuk’s session, I couldn’t help thinking of Java Champion Cay Horstmann who, in a recent interview, spoke at length about the “stack trace from hell” problem in relation to JavaServer Faces, which he perceives as fundamentally flawed. He seemed to believe that no matter how good your tools for identifying the problem, “When something goes wrong, the app server just belches and whines -- it has no pathway to propagate an error with file name and line number to the development environment.” NetBeans scrapes the stack trace for clues, but as Horstmann puts it, “they can only report what the app server tells them. The app servers need to have a development mode that tells the IDE the precise file name and line number that caused a failure.”
In a discussion of this issue on theserverside.com that had 13 responses, Horstmann displayed a “stack trace from hell” with more than 700 lines. He concludes: “There simply has to be a better way to get this report back to the IDE than scraping the stack trace. I am not sure who should take ownership of this issue, but there sure are a lot of people who say ‘it's not my department...’"
Horstmann was focusing on NetBeans operating at a different level of analysis, but I wonder if the principle applies equally here. Perhaps in software applications as in life, doctors are only as good as their patients.
Learn more about Sun Tech Days.
Janice J. Heiss