 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 326: Post mortem JVM Diagnostics API
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: A standard Java API designed to support the generation and consumption of post mortem or snapshot Java diagnostic artefacts. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant The following information has been updated from the original proposal.
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The final specification license is here.The final RI and TCK license is here. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: IBM Name of Contact Person: Steve Poole E-Mail Address: spoole@uk.ibm.com Telephone Number: +44 (0) 1962 818696 Fax Number: +44 (0) 1962 818999 Specification Lead: Steve Poole E-Mail Address: spoole@uk.ibm.com Telephone Number: +44 (0) 1962 818696 Fax Number: +44 (0) 1962 818999 Initial Expert Group Membership: - Supporting this JSR: Apache Software Foundation Section 2: Request
2.1 Please describe the proposed Specification:A standard Java API designed to support the generation and consumption of post mortem or snapshot Java diagnostic artefacts. The specification will be inclusive of a range of existing ?in field? diagnostic artefacts: including common operating system dump formats. The specification will balance the need to provide maximum value from existing artefacts, while considering the problem space expected to be encountered in the near and longer term future, with multiple language environments and very large heaps 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java SE. Desktop and server environments 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This JSR is targeted at Java SE as a runtime environment. As a diagnostics specification it is applicable for use against diagnostic artefacts from the Java EE and Java ME platforms. Although there is no expectation that the first version of this API will include handling Java ME diagnostic artefacts, the design does not preclude its addition in the future. Should this JSR be voted on by both Executive Committees?No. 2.5 What need of the Java community will be addressed by the proposed specification?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. 2.6 Why isn't this need met by existing specifications?There are no standard Java APIs that provide facilities for the interrogation of post mortem or snapshot artefacts from the various Java Virtual Machines and associated operating systems. Existing tools do provide individual subsets of the capabilities needed. However the form and reach of these tools is not as extensive as it needs to be to help diagnose all the types of problems envisaged. These tools are generally not available in all required environments, not defined by a Java API specification or missing important diagnostic capabilities. 2.7 Please give a short description of the underlying technology or technologies:Using existing technologies as a model, and as a lesson in integrating diagnostic data formats for different purposes, the Expert Group will determine the relevant form and scope of the specification. The specification will need to recognise that a single one-size-fits-all approach is not sensible given the broad range of diagnostic artefacts that exist today. An approach is needed that allows different types of artefact to be usefully included, while still allowing easy extension to cope with future areas such as additional language runtime support Finally it is expected that a API will be created to standardize the way of generating diagnostic snapshots of a in-flight system. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.tools.diagnostics 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?The reference implementation will provide diagnostic artefact specific readers as appropriate ? some of these will be operating system specific but they have no dependencies as described 2.10 Are there any security issues that cannot be addressed by the current security model?No. 2.11 Are there any internationalization or localization issues?No issues are expected. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. 2.13 Please describe the anticipated schedule for the development of this specification.First Early Draft Review by end of 1Q 2009. Proposed Final Draft during 3Q of 2009. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.It is intended that this JSR will be developed in a wide, community led, transparent way. To ensure this, the reference implementation, specification and TCK will be developed in a publicly accessible open source manner. The modus operandi of the chosen community will be adopted as the working model for the development of the RI, Specification and TCK. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.Beyond the transparency offered by the development of the JSR in an open source manner, there will be focus on the publication and discussion of the reference implementation via weblogs, articles, newsgroups, forums etc. The primary mailing list for discussion on the development of the JSR will be open to all of the Java community. Since the development of the specification for this JSR will be driven by the reference implementation it will be available at all times for comment by the public. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The reference implementation and TCK will be developed separately from the JAVA SE platform and made available externally as a stand-alone offering. The preferred goal is for the API, framework and common data source providers to be included in a future version of Java SE. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).There are no prior versions. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.NOTE that this information has been updated from this original proposal. The Reference Implementation and TCK will be made freely available in both binary and source form on a no charge basis under an OSI approved licence Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Some examples of existing technologies within the domain relevant to this JSR are listed. This is not an exhaustive list and is not intended to indicate that this specification will consume any or all of these technologies. 1) HPROF: http://java.sun.com/developer/technicalArticles/Programming/HPROF.html 2) IBM Diagnostic Tool Framework for Java: http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.diagnostics.60/diag/tools/dtfj.html 3) Java Debug Interface: http://java.sun.com/javase/6/docs/jdk/api/jpda/jdi/index.html 4) Hotspot Serviceability Agent: http://openjdk.java.net/groups/hotspot/docs/Serviceability.html#bsa 3.2 Explanation of how these items might be used as a starting point for the work.These data providers and others, plus associated APIs and relevant tools, will be used as guidance material in determining the format of the specification created by this JSR. |
||||||||||||||||||||||||||||||||||||
