 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 163: JavaTM Platform Profiling Architecture
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: A mechanism and APIs for extracting time and space profiling information from a running JavaTM virtual machine. Please direct comments on this JSR to the Spec Lead(s) Team
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Robert Field E-Mail Address: Robert.Field@sun.com Telephone Number: +1 408 276 7074 Fax Number: +1 831 427 1088 Specification Lead: Robert Field E-Mail Address: Robert.Field@sun.com Telephone Number: +1 408 276 7074 Fax Number: +1 831 427 1088 Initial Expert Group Membership: Sun Microsystems,Inc Supporting this JSR: Sun Microsystems,Inc Section 2: Request
2.1 Please describe the proposed Specification:The specification will be for APIs to extract profiling information from a running Java[TM] virtual machine. Both
time and memory profiling will be supported. Both sampling and exact mechanisms will be supported. The APIs
will be designed to allow implementations which minimally perturb the profile. The APIs will allow inter-operability of profiling and
advanced garbage collection technologies. The APIs will allow reliable implementation on the widest range of virtual machines, part of which
will be achieved by grouping functionality into optional sets. The APIs will accommodate implementations which can dynamically enable and disable profiling; and thus will allow implementations which have negligible performance impact when profiling is disabled. While profiling in the application development phase will be the primary goal of this specification, the design objectives for low performance overhead and data perturbation will also support profiling in the deployment phase. A Technology Compatibility Kit (TCK) will be provided. The Reference Implementation will include a sample profiling tool. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Desktop and server platforms are the target for this work but an effort will be made to design systems which will work well in or be adaptable to smaller systems and to emulators for smaller systems. The design will allow the creation of platform independent profiling tools - to achieve this a wire protocol and remote Java programming language API will be part of the API set. 2.3 What need of the Java community will be addressed by the proposed specification?Lack of a standardized interface is impeding tool development and VM support, since companies are awaiting a standard. 2.4 Why isn't this need met by existing specifications?All that currently exists is the experimental interface - the JavaTM Virtual Machine Profiling Interface (JVMPI). It suffers from a number of design flaws which cause it to be difficult to implement reliably, particularly in modern virtual machines, and which induce overhead which significantly perturbs the resulting profile. Its heap profiling mechanism does not scale. It is not compatible with modern garbage collectors. It has no defined extension mechanism. It has resulted in incompatible implementations since it is insufficiently specified and has no compliance definition or test suite. The native only interface requires tool vendors to write an agent for each platform, as a result only the most popular platforms are supported. 2.5 Please give a short description of the underlying technology or technologies:There are several options - technology to be developed by the expert group. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Not yet. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?None known at this time. 2.9 Are there any internationalization or localization issues?No. Although a sample tool might have such issues. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?JVMPI will be rendered obsolete and will be removed as soon as this JSR is completed and included in a J2SE release. Inter-operability with existing and planned tool interfaces is desirable. A possible approach to inter-operability is extension to existing interfaces, such as the JavaTM Platform Debugger Architecture (JPDA). 2.11 Please describe the anticipated schedule for the development of this specification.For inclusion in the J2SETM Tiger release. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Primary working model will be email communication. Teleconference or physical meeting could be used. 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.No existing documents. 3.2 Explanation of how these items might be used as a starting point for the work.N/A Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
