Minor change in JFR file format
Jason Fordham
jclf at azul.com
Mon Dec 12 20:03:26 UTC 2022
Hi Erik,
> Sometimes the size of a check point event can be larger than what can
> fit in an integer (32-bits). Both the JDK and JMC parser read the size
> field as a compressed long, but casts it to an int. In JMC, see
> SeekableInputStream:
>
> int CompressedIntsDataInput::readInt() throws IOException {
> return (int) readCompressedLong();
> }
>
> ChunkLoaderV1::readConstantPoolEvent(...)
>
> Today:
> input.readInt(); // size
>
> Should be changed to:
> input.readLong(); // size
>
> We are considering bumping the minor version (a non-breaking change) of
> the file format, but we are not sure if it is necessary as it was already
> treated as a long value by the JMC parser?
>
> It's more of a problem for the JDK parser, it checks that the number of
> bytes read matches that of the event size, but since it is already broken
> for large check point events, a change will not make it more broken. See
> this JDK bug for details:
> https://bugs.openjdk.org/browse/JDK-8298129
>
> This change will not impact the size of ordinary events.
I thought you should know that this issue is not purely theoretical: it
actually came up at a customer site, and they reported that
InvalidJfrFileException occurred for "multiple hosts on production
instances". This led to us providing them with a short-term fix, and
opening JDK-8297402. They're using their own jfr reader, and using the
JMC parser classes.
It's possible that the customer would like to be able to read their
historical collection of JFRs using a single tool, and I believe the new
parser code for command line jfr and the JMC GUI will still fail for any
existing recordings that need more than 28 bits to encode an integer
value. If this doesn't make up your mind to bump the minor version
number, would you mind waiting to make a decision on this until I've
heard back from the customer to see if they need to continue to read
existing JFRs?
Kind regards,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20221212/a37f8139/attachment.htm>
More information about the jmc-dev
mailing list