RFR: 8297402: jfr tool processes large padded integers incorrectly

[Erik Gahlin]

On Tue, 22 Nov 2022 15:06:20 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> Could I have a review of a PR that fixes jfr tool reading of large padded integers.
> 
> Some integer values are written to jfr recordings using write_padded_at_offset<u4>() method. Their size in recording is always 4 bytes.
> jfr tool reads all integer values by readInt() method, which doesn't take size into account.
> For padded values greater than (1 << 28), jfr tool tries to read 5 bytes from recording and fails.
> 
> I suggest to fix reading of padded integers in jfr tool.
> If a value is written by write_padded_at_offset<u4>() then it should be read by readPaddedInt() method which doesn't read more than 4 bytes.
> (It can be less then 4 bytes due to JDK-8246260)
> 
> Tested with jdk/jfr and tier1.
> jfr recording generated by TestHugeStackTracePool.java with jdk11 (attached to JDK-8297402) is successfully processed by jfr tool after the fix.

Maybe I am missing something, but the reason padded integer are used is because the size is not known until all the data has been written for an event, so the JVM/JDK reserves 4 bytes up front and if not all bytes are used, leftmost bytes are padded with 128, which corresponds to 0. 

If data can't fit in 2 ^28, maybe the JVM should split the data into two events? The JVM should not write data that indicates a fifth byte can be read. I think this is where the bug is. 

Markus has done some work in the area.

-------------

PR: https://git.openjdk.org/jdk/pull/11289