JVM performance dashboard
Original Publication Date: 2004-Jul-29
Included in the Prior Art Database: 2004-Jul-29
Proposal for a new feature enabling the JVM (Java Virtual Machine) to provide information about its performance status at runtime.
JVM performance dashboard
This new feature mainly consists of a dashboard containing indicators related to internal operations of the JVM and a subcomponent assigned to its life cycle.
The content of the dashboard must be available internally to the application and it may be also available externally on-demand by means of the same subcomponent. Finally, this mechanism can bring effective value if it is though of as lighter as possible, with a little impact on the JVM itself.
When a java application is running, it is possible to sample externally its performance behaviour by means of measurements supplied by OS utilities. The JVM is a black box and we try to make the point on its health looking at:
· virtual memory size
· real memory size
· swapping memory size
· CPU percentage
· other such metrics.
In case of suspected or evident problems (memory leaks, too much CPU, etc.), it is quite difficult to analyse data and figure out where the problem resides, whether there is an object leak inside the java heap, or the disruption is rather in the native heap, or there is a deadlock condition among threads, etc. This is particularly true when taking into account the complexity of the majority of J2E applications.
Let's consider which instruments we can leverage to achieve similar purposes.
verbose:gc launching option
This CLI (Command Line Interface) option, when specified, allows activating the trace on GC (Garbage Collector) operations: how much memory is needed in the java heap for new objects, what is the available space in the heap after a new GC cycle occurs. Different implementations of this option generate more or less verbosity in the output (IBM JVM vs. Sun JVM).
Drawback: the metric subset isn't complete because there are only metrics about the java heap; moreover this approach doesn't fit the on-demand strategy.
Only available for the IBM JVM. Sending the SIGQUIT signal to the JVM (kill -3 <pid>) a text file is produced: it supplies complete information on the java environment, the system environment, all the running threads with the java and native stack for everyone and all loaded classes.
Drawback: javacore text files are quite exhaustive but they don't fit easily in an autonomic strategy aiming to let J2E applications to self diagnose their health and eventually recover problems.
When javadumps are enabled, a snapshot of the java heap is put in a text file. This file is hardly intelligible unless it isn't processed through external tools to extract useful information: which are the first N classes consuming most space in the heap, objects kept alive longer than they should be etc.
Drawback: once more, only memory metrics and no flexibility for the on-demand scenario.
The Figure presents the architecture for the proposed feature. The key logical components are: