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

Chris Plummer cjplummer at openjdk.org
Tue Oct 15 22:26:10 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

src/hotspot/share/prims/jvmtiThreadState.hpp line 364:

> 362:   void set_top_frame_is_exiting() { _top_frame_is_exiting = true;  }
> 363:   void clr_top_frame_is_exiting() { _top_frame_is_exiting = false; }
> 364:   bool is_top_frame_is_exiting()  { return _top_frame_is_exiting;  }

Just noticed you are using "is" twice in this API. I'm not sure of the hotspot convention here. Seems probably the first "is" should be dropped.

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

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


More information about the serviceability-dev mailing list