RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v27]

Martin Doerr mdoerr at openjdk.org
Wed May 21 15:55:05 UTC 2025


On Tue, 20 May 2025 16:13:23 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

> > Heads-up: I'm currently testing the PPC64 implementation: [TheRealMDoerr at 9b9f0bf](https://github.com/TheRealMDoerr/jdk/commit/9b9f0bfc06d63110d99ef32553a0dff58cf69136) Note that I'm not using memory barriers. I'm relying on synchronization by the suspend/resume mechanism (as well as the signal handler in case of async profiler). Especially the StoreLoad barrier in the remove_activation code has probably interpreter performance impact.
> 
> That is great news Martin! Thanks for testing without the barriers. If you are ok without them on PPC, they are most likely not needed on any other platform.

Updated version (`InterpreterRuntime::at_unwind` before `notify_method_exit`): https://github.com/TheRealMDoerr/jdk/commit/20826e59b088e42cda50008b4a91b5895e0630b3

I have seen intermittent failures in TestResidentSetSizeEvent.java:

java.lang.RuntimeException: Should be non-zero: expected 0 > 0
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
	at jdk.jfr.event.runtime.TestResidentSetSizeEvent.verifyExpectedEventTypes(TestResidentSetSizeEvent.java:81)
	at jdk.jfr.event.runtime.TestResidentSetSizeEvent.main(TestResidentSetSizeEvent.java:92)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

I don't see any relationship to my changes. Could be related to large pages on the machine.

I'll try more tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24296#issuecomment-2898457079


More information about the hotspot-jfr-dev mailing list