RFR: 8297402: jfr tool processes large padded integers incorrectly

[Ekaterina Vergizova]

On Wed, 23 Nov 2022 21:48:16 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Currently, the JVM does not check 2 ^ 28 limit in most cases when writing padded integers.
>> For example, it doesn't validate or reject values for a large pool of stacktraces.
>> 
>> If such values are actually invalid, then I'll try to prepare a fix that splits the data into two events, if possible.
>
> Hi @kvergizova, thanks for noticing this.
> 
> I ran into this situation a couple of months back and have an idea and suggestion to handle this situation. If you don't feel like digging too deep, I can either help you or take over this entirely.
> 
> Best regards
> Markus

Hi @mgronlun, thanks for the respond, I really appreciate your help.

I have two different ideas how to handle this issue: 

- update WriteContent, Content and their derivatives to write a subset of elements in process() methods and check for 2^28 size overflow during writing. If an overflow occurs, duplicate the event header and process the rest of the elements.
- reserve 5 bytes instead of 4 for some padded integers that are potentially prone to overflow if LEB128 encoder is used (e.g. checkpoint event size for stack traces or string pool). This seems to be pretty easy to implement, but will result in a slight increase in jfr recordings size.

What do you think about it and what is your suggestion?
If you prefer to take over this issue entirely and plan to do so in the near future, that would also be great.

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

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