Add JDK Flight Recorder support for Java native images

[adinn]

Synopsis

This issue proposes to add JDK Flight Recorder (JFR) support for Java native images for monitoring and performance profiling of applications.

A prototype implementation is in progress, and work is ongoing to finalize the initial feature set for contribution to Graal CE. We welcome feedback from Oracle’s GraalVM team and the GraalVM community on both this proposal and the prototype implementation (which we will soon publish as a draft PR).

The prototype preserves and reuses existing Java APIs (jdk.jfr.*) together with a new Java-based implementation of the underlying system (currently under com.oracle.svm.core.jdk.jfr.*). This implementation closely resembles the native implementation in OpenJDK HotSpot (hotspot/share/jfr). Event instrumentation is forced during the analysis stage and reused in the resulting native image.

Proposed Initial Additions

• Provide compile-time configuration to include or exclude the JFR infrastructure
• Support existing OpenJDK API to start, stop and dump JFR v2.1 compliant recording files (.jfr) during native image run (jdk.jfr.Recording and related classes)
• Allow command-line options to configure recordings on start-up, similar to the options in OpenJDK
• Support build-time inclusion of application-defined events derived from jdk.jfr.Event and related classes
• Emit OpenJDK Java specific events (Socket/File read/write, ExceptionThrown, etc.)

Proposed Long-Term Additions

• Emit SubstrateVM specific events for memory allocation, garbage collection and other SubstrateVM subsystems
• Support JFR crash dumps
• Support leak profiling
• Add Thread and Stack Trace data for events
• Provide remote API to start, stop and dump recordings

Expected Benefits

• Native image execution monitoring and tracing
• Native image performance profiling via JFR file analysis
• Existing Java users and applications can migrate to native image with JFR available

Limitations

• No dynamic events created at runtime

[thegreystone]

Is support for the jdk.ExecutionSample event, or a true CPU profiling event, part of this effort?

[jiekang]

@thegreystone Support for jdk.ExecutionSample or similar is part of the overall effort but for a currently unknown future date.

[jerboaa]

The WIP PR for this is here: #3070

[jiekang]

The initial support has made it into upstream via #3444

I think this issue can be closed as 'done'. There is more work to do to complete the implementation but those will be covered in separate, specific issues.