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

[Chris Plummer]

On Thu, 17 Oct 2024 23:11:22 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:
> 
>   no need in raw monitor - removed

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 66:

> 64:   char* name = nullptr;
> 65: 
> 66:   pop_count++;

I think there is still a concern that once this increment is done, the next iteration in control() can start. It will try to suspend this thread, which I think can happen in the 3 JVMTI calls below, and controll() will then call NotifyFramePop(), which will clobber last_notify_method. I think just moving this increment to the end will resolve that issue, or at least move it to after the last_notify_method reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805577010