RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning [v5]
Chris Plummer
cjplummer at openjdk.org
Thu Oct 17 22:01:46 UTC 2024
On Thu, 17 Oct 2024 21:50:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
>> Yes, this is all very synchronous. The control thread suspends the thread, we call NotifyFramePop on the thread, the control thread resumes the thread and then waits for confirmation of the FRAME_POP before repeating the process. I'm not sure what motivated the change to add old_notify_method. Maybe there was some other issue that was misunderstood.
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805493986
More information about the serviceability-dev
mailing list