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

Serguei Spitsyn sspitsyn at openjdk.org
Thu Oct 17 23:15:55 UTC 2024


On Thu, 17 Oct 2024 21:58:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Control thread waits until pop_count is updated and FramePop callback updates it at the beginning, so control thread can start next iteration (i.e. call SuspentThread) before FramePop is completed.
>> But my understanding that SuspentThread cannot return before FramePop completed, so there is no synchronization issues here
>
> Actually I'm not so sure of your last statement. I think while in the FramePop callback the thread can do things that allow it to be suspended. So if the control thread has already detected that FramePop callback has been called, it may move on to the next iteration before the FramePop callback completes.

Agreed, thanks.
The suspend should happen in the `ThreadInVMfromJava()` destructor that is a part of the `JRT_BLOCK` macro.  I've pushed the fix now.

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

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


More information about the serviceability-dev mailing list