Minor change in JFR file format

[Jason Fordham]

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>