Printed: Feb 7, 2012
From: http://www.jcp.org/en/jsr/detail?id=163&
|
| Specification Leads | |||
| Robert Field | Oracle | ||
| Expert Group | |||
| Apple Computer, Inc. | ARM Limited | BEA Systems | |
| Borland Software Corporation | Candle Corporation | Hewlett-Packard | |
| Hitachi, Ltd. | IBM | Intel Corp. | |
| Metrowerks | Opnet Technologies, Inc | Oracle | |
| SAP AG | Sitraka | Sun Microsystems, Inc. | |
| Wily Technology, Inc. | |||
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
IBM
Wily Technology
Sitraka
Rational Software
Compaq Computer Corporation
Borland Software Corporation
Redline Software
Apple Computer
Supporting this JSR:
Sun Microsystems,Inc
IBM
Wily Technology
Sitraka
Rational Software
Compaq Computer Corporation
Borland Software Corporation
Redline Software
Apple Computer
Section 2: Request
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.
Queries for which optional capabilities are supported will be provided. An API will be provided by which containers may bill work to a component. The APIs will
be targeted to provide a Java programming language model of execution, however, some aspects of the virtual machine, native and operating system
models may be directly provided or provided via an extension mechanism.
The APIs will be intended to supersede the current experimental interface - the Java Virtual Machine Profiling Interface (JVMPI) - and thus must provide roughly
comparable functionality.
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.
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.
Lack of a standardized interface is impeding tool development and VM support, since companies are awaiting a standard.
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.
There are several options - technology to be developed by the expert group.
Not yet.
No
None known at this time.
No. Although a sample tool might have such issues.
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).
For inclusion in the J2SETM Tiger release.
Primary working model will be email communication. Teleconference or physical meeting could be used.
Section 3: Contributions
No existing documents.
N/A
Section 4: Additional Information (Optional)
None.