RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning [v2]

Alex Menkov amenkov at openjdk.org
Wed Oct 16 00:40:11 UTC 2024


On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment tweak

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @summary Verifies NotifyFramePop request is cleared if JVMTI_EVENT_FRAME_POP is disabled

Summary does not look correct

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 37:

> 35: public class NotifyFramePopStressTest {
> 36:     static volatile boolean done = false;
> 37:     static volatile int notifyCount = 0;

don't need to be volatile (actually it can be local in `control` method)

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 129:

> 127: 
> 128:     private static int foo() {
> 129:         return fetchInt();

The test checks name of the method being popped.
I think it would be better to call different methods from `foo()` and `bar()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802157865
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802159018
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802157540


More information about the serviceability-dev mailing list