On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn <sspit...@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
test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
line 26:
> 24: /**
> 25: * @test
> 26: * @summary Verifies NotifyFramePop request is cleared if
> JVMTI_EVENT_FRAME_POP is disabled
Summary does not look correct
test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
line 37:
> 35: public class NotifyFramePopStressTest {
> 36: static volatile boolean done = false;
> 37: static volatile int notifyCount = 0;
don't need to be volatile (actually it can be local in `control` method)
test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
line 129:
> 127:
> 128: private static int foo() {
> 129: return fetchInt();
The test checks name of the method being popped.
I think it would be better to call different methods from `foo()` and `bar()`
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802157865
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802159018
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802157540
