Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 163: JavaTM Platform Profiling Architecture

Stage Access Start Finish
Final Release Download page 30 Sep, 2004  
Final Approval Ballot View results 31 Aug, 2004 13 Sep, 2004
Proposed Final Draft Download page 10 May, 2004  
Public Review Download page 02 Sep, 2003 30 Nov, 2003
Community Draft Ballot View results 22 Jul, 2003 28 Jul, 2003
Community Review Login page 23 Jun, 2003 28 Jul, 2003
Expert Group Formation   23 Jan, 2002 11 Apr, 2003
JSR Review Ballot View results 08 Jan, 2002 22 Jan, 2002
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

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)

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 SE 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:

Telephone Number: +1 408 276 7074

Fax Number: +1 831 427 1088

Specification Lead: Robert Field

E-Mail Address:

Telephone Number: +1 408 276 7074

Fax Number: +1 831 427 1088

Initial Expert Group Membership:

Sun Microsystems,Inc
Wily Technology
Rational Software
Compaq Computer Corporation
Borland Software Corporation
Redline Software
Apple Computer

Supporting this JSR:

Sun Microsystems,Inc
Wily Technology
Rational Software
Compaq Computer Corporation
Borland Software Corporation
Redline Software
Apple Computer

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.
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.

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?


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.


Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.