P3
To reduce the file size of a JFR recording, JEP C148 introduced a file format where integer values can be written in a compressed format.
To simplfy debugging, when the code was unstable, we kept the infrastructure for writing uncompressed integers and added the option -XX:FlightRecorderOptions=compressedintegers=false. This increases the risk of bugs, since we have to support two file formats.
There are several ways we can go about this:
1) Don't document -XX:FlightRecorderOptions=compressedintegers=false so it is not known to people outside the JVM organization.
2) Remove the option, but keep the infrastructure. If we run into problems, we can build a new JDK where data is written in an uncompressed format.
3) Remove the option and the infrastructure, which will reduce maintenance cost and also improve performance somewhat for native events.
It's unclear what route we want to take for JDK 9 at the moment. We may need to split this bug into two, one for JDK 9 and one for JDK 10.
To simplfy debugging, when the code was unstable, we kept the infrastructure for writing uncompressed integers and added the option -XX:FlightRecorderOptions=compressedintegers=false. This increases the risk of bugs, since we have to support two file formats.
There are several ways we can go about this:
1) Don't document -XX:FlightRecorderOptions=compressedintegers=false so it is not known to people outside the JVM organization.
2) Remove the option, but keep the infrastructure. If we run into problems, we can build a new JDK where data is written in an uncompressed format.
3) Remove the option and the infrastructure, which will reduce maintenance cost and also improve performance somewhat for native events.
It's unclear what route we want to take for JDK 9 at the moment. We may need to split this bug into two, one for JDK 9 and one for JDK 10.