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

[Alex Menkov]

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

>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 171:
>> 
>>> 169:   } else {
>>> 170:     char* old_notify_method = (char*)last_notify_method;
>>> 171:     last_notify_method = name;
>> 
>> I don't think this adds reliability.
>> Control thread suspends main test thread before call this method. AFAIU suspend cannot complete before FramePop callback is completed.
>
> 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

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

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