8242593: JFR: EventFactory does not scale well past unique 1000 event

[Erik Gahlin]

Hi Jaroslav,

Thanks for reviewing the patch. There is no test and rather not add one.

The only way to provoke the issue to crash the JVM. It can be done in a 
test, but those kind of test are often flaky and a pain to maintain. The 
code that that adds a histogram entry is trivial and I have verified 
manually that events with missing metadata shows up. It should be 
sufficient.

Thanks
Erik

On 2020-06-22 10:27, Jaroslav Bachorík wrote:
> Hi Erik,
>
> The patch looks good! I wonder, is there a test already for the
> Summary.java which asserts it can properly handle the missing
> metadata?
>
> Cheers,
>
> -JB-
>
> On Sat, Jun 20, 2020 at 6:06 PM Erik Gahlin <erik.gahlin at oracle.com> wrote:
>> Hi,
>>
>> Could I have review of a fix that prevents metadata to be written to
>> native every time a new event is registered.
>>
>> This means there is small chance that the JVM will not be able to write
>> the most recent metadata if a crash occurs and an emergency recording is
>> created. This will not impact ordinary recordings or event streaming,
>> since stale metadata is written out before a segment or chunk is complete
>>
>> For more details, see:
>>
>> https://mail.openjdk.java.net/pipermail/jmc-dev/2020-June/002279.html
>>
>> If the parser finds an event that lacks metadata, it will just skip that
>> event. This will only occur if the JVM crashes within 1 second after new
>> Java event is registered.
>>
>> I did a small experiment and the time it takes to register 50 events now
>> drops from 350 ms to 50 ms.
>>
>> I also updated the 'jfr summary command', so it prints the event id if
>> the metadata is missing. This makes it possible to verify that an event
>> missing due to lack of metadata and not a configuration issue etc.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8242593
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8242593/
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>>
>>