JDK-8230764 : JFR Backport
  • Type: CSR
  • Component: hotspot
  • Sub-Component: jfr
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 8-pool
  • Submitted: 2019-09-09
  • Updated: 2020-01-08
  • Resolved: 2019-12-20
Related Reports
Blocks :  
JMC-6620 - Update JMC to properly detect OpenJDK 8 implementation of JFR
CSR :  
JDK-8223147 - JFR Backport
Description
Summary
-------

Backport of JFR infrastructure, tooling and APIs to OpenJDK8u

Problem
-------

We would like to request a compatibility review for the backport work we are doing regarding the JFR project from later version of OpenJDK to OpenJDK8u.

We believe that most of the work is hidden from users. The API being added are not part of the specification for Java8 (reside under the jdk.jfr namespace introduced in Java 11) and the command line options are in the "-XX" flag that signal extra/unsupported options.

Currently, the work for the backport is done in an incubator repository, we believe the repository contains now most of the changes necessary and is suitable for a review:

http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/

Specification
-------------

* Addition of libraries in the jdk.jfr namespace

  - This is being worked currently as a separate jfr.jar that users will have to link specifically. An empty implementation is also being worked on for compatibility mode.

* The jfr tool will be introduced in bin/

* The MBean interface to control JFR will be introduced

* Extra command line options will be introduced in the java lancher. like:

-XX:+FlightRecorder
-XX:StartFlightRecording
-XX:FlightRecorderOptions

If Flight recorder is present, the behavior is the same as the current Oracle 8 JDK, otherwise the behavior does not change.

The jdk.jfr API is optional.
Comments
Thanks!
08-01-2020
Moving to Approved.
20-12-2019
[~hirt] or others work on this request, please include some representation of the API changes of this request to the request in some way, for example, a zip of the webrev of the API files or a zip of the javadoc. Afterward, the request can be Finalized for the second phase of CSR review. Thanks,.
18-12-2019
Hi Joe! Great to see progress here - thank you!
16-12-2019
Moving to Provisional. Sorry again for the longer than expected latency. The backport of the API looks appropriate for the goals of the project. I recommend adding package-info.java files to the directories with public APIs.
16-12-2019
Sorry again for the delay, I'm working to clear the CSR backlog ahead of Thanksgiving next week. Yes, the process is for the CSR to be in Approved state before being pushed.
23-11-2019
Hi Joe, Is there anything else I should be doing to move this forward? We are aiming at a release date for April (i.e. merge shortly after the January release). While we can have the build flags to default to not build JFR support (basically preserving the status quo), I believe we still need this CSR resolved before we can commit the changes, is that right? Thanks again! Mario
22-11-2019
Hi, Just a quick addition, we started working on a compatibility library for the Flight Recorder APIs, while this isn't necessarily directly related to the backport (and in fact, the backport would all but render this less meaningful), I think it would offer a migration path with JDKs that do not have the jfr.jar library: https://github.com/rh-jmc-team/openjdk8-jfr-compat Cheers, Mario
03-10-2019
Hi Joe, > The user-visible API of jfr.jar should be provided in the CSR in some fashion, such as a zip of the javadoc. > A conceptual statement of the intentions of the API should be provided too such as > "Matching of API of the the jdk.jfr from JDK 11" or whatever the semantics of the backport are. I uploaded the resulting jar file with the jfr api here: http://cr.openjdk.java.net/~neugens/jfr-8u-backport/jfr.jar The APIs added are in the following namesapces: jdk.management.jfr.* jdk.jfr.* Currently this jar file is generated under the j2re-image/lib but we can of course move it to the ext if this is a better approach. The purpose of the API is indeed to match the API of the jdk.jfr from JDK 11. > Presumably a JFR backport would involve at least some "product" and/or "manageable" flags, > in which case the CSR should list them and highlight any differences from the existing JFR implementations. Similarly to what happens in 11 those flags are hidden and need to be manually specified, the help does not mention them either. However, there is a management interface to enable those flags at runtime so I agree it qualifies as "management". I don't know what are the difference with Oracle JDK 8, there is no difference within OpenJDK implementation however. Also Mission Control is able to get information from an OpenJDK 8u with the flight recorded patches without modification of the internal logic (with the exception of recognising OpenJDK 8u as a JFR compatible JVM, which was rejected only based on the version scheme). The command line arguments we added are the following: -XX:StartFlightRecording -XX:FlightRecorderOptions They also enable a number of options: -XX:StartFlightRecording=maxsize -XX:StartFlightRecording=maxage -XX:StartFlightRecording=settings -XX:StartFlightRecording=disk -XX:StartFlightRecording=disk -XX:StartFlightRecording=dumponexit -XX:StartFlightRecording=filename Those are all the options that show up when running java -XX:+PrintFlagsFinal: EnableTracing FlightRecorder FlightRecorderOptions LogJFR StartFlightRecording UnlockCommercialFeatures The management interface adds a new bean name: "jdk.management.jfr:type=FlightRecorder" In addition to the jdk.management.jfr APIs, most notably the jdk.management.jfr.FlightRecorderMXBean that allows us to operate JFR via JMX and via jcmd. jcmd lists the following options when asking to the target jvm with the JFR backport: VM.unlock_commercial_features JFR.configure JFR.stop JFR.start JFR.dump JFR.check I hope this is exhaustive, if you need more details, I'll be happy to answer every questions! Cheers, Mario
03-10-2019
This request is out of the ordinary and will need some additional information to be provided before finalizing. The user-visible API of jfr.jar should be provided in the CSR in some fashion, such as a zip of the javadoc. A conceptual statement of the intentions of the API should be provided too such as "Matching of API of the the jdk.jfr from JDK 11" or whatever the semantics of the backport are. The HotSpot flags have a complex taxonomy and documented relationship to the CSR: https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process Presumably a JFR backport would involve at least some "product" and/or "manageable" flags, in which case the CSR should list them and highlight any differences from the existing JFR implementations.
03-10-2019