RFR: 8275338: Add JFR events for notable serialization situations [v4]

Erik Gahlin egahlin at openjdk.org
Tue Dec 19 17:27:54 UTC 2023


On Tue, 19 Dec 2023 16:00:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50:
>> 
>>> 48:  * @requires vm.hasJFR
>>> 49:  * @library /test/lib
>>> 50:  * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent
>> 
>> Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion.
>
> Not sure, I have to check.

All the other events run in othervm. While it may be possible in some case to not do that, it's much easier to analyse issues, if we are sure the JVM is fresh. For example, JFR may not generate bytecode if an event is disabled. The JFR tests have been hardened to be able to run in parallel, so they run pretty fast.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431727571


More information about the core-libs-dev mailing list