RFR: 8297402: jfr tool processes large padded integers incorrectly

[Markus Grönlund]

On Mon, 28 Nov 2022 16:41:34 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

>> 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.

Hi @kvergizova, there is a way to handle this situation, specifically for checkpoint events. Since the raw information for these events are stored in-memory, in a queue before serializing to disk, it is possible to know how much space will be needed and make a reservation as a function of that. I have a patch in progress, so I can take over this issue.

Thanks
Markus

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

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