IBM has submitted JSR-326: Post mortem JVM Diagnostics API to the Java Community Process (JCP). According to the JSR,
Existing Java diagnostic tools are focused primarily on what can be termed "live monitoring" - this means source level debuggers, trace tools, performance analysers etc. These tools are very useful when the problem is readily reproducible and the customer is willing to accept the costs of such reproduction. However, in many cases problems do not fall into either of these categories as the problem is either intermittent or the impact of reproduction with live monitoring tools is too expensive. In these cases the pressure is then on those supporting the customer to solve the issue in other ways. Here we enter the realm of post mortem analysis as the primary means for uncovering the cause of the issue. Unfortunately this space is fragmented and incomplete.
The lack of pervasive and credible post mortem and snapshot diagnostic tools has steadily driven the problem solving act down the software stack. The result is that JVM and middleware providers have become increasingly involved in helping customers determine root cause for a wide variety of unexpected application behaviour. This trend is increasing in line with the exploitation of capabilities introduced in Java SE. For instance, Java 5.0 NIO brought managing native memory back to the table. Something most Java programmers had not had to learn before. Helping customers diagnose native out of memory situations is a common occupation for JVM and middleware providers.
In the short term, we need to see the development of a tools ecosystem that will result in a substantial increase in tools that can provide diagnostic information suitable to allow vendors and customers alike to solve problems in an isolated manner. Since third-party vendors are generally unwilling to invest in developing these tools due to the lack of standard APIs for interrogating diagnostic artefacts, the actual short term goal is to create the relevant APIs and develop cross platform implementations targeted at the JVMs and operating systems in use today. Note the point implied -- all versions of JVM's need to be considered -- this is not just a Hotspot JVM or a JAVA SE 6.0 problem. It is not sufficient to develop a solution that can only be useful if customers have to migrate to the latest level of JVM. It is highly important that as far as possible the solutions developed are inclusive of existing, "in field", JVMs and operating systems and do not mandate changes to those technologies. Therefore the Expert Group will have to consider the needs of all JVM vendors and versions of Java SE.
In the longer term we also need to be able to address the scale and complexity issues raised in diagnosing problems in the world of 64bit, multiple VM, multiple vendor, multiple language environments. It will take time to identify and agree the approaches needed in tackling these problems. A common API is a necessary precondition if we wish to maintain the value and credibility of this arena.
Comments are due by August 8.