On Tue, 30 Jul 2024 23:13:23 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> The test has been fixed to:
> - add a guard against JVMTI_ERROR_WRONG_PHASE
> - replace `exit(err)` with `abort()` in the `check_jvmti_error()`
>
> The JVMTI `VMDeath` event is enabled and a `RawMonitor` is introduced to
> serialize `ClassPrepare` and `VMDeath` events, and so, to prevent
> JVMTI_ERROR_WRONG_PHASE in the `ClassPrepare` events.
>
> Testing:
> - run the test AllowedFunctions.java locally
> - TBD: submit a mach5 run for fixed test
test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/libAllowedFunctions.c
line 358:
> 356:
> 357: // Block VMDeath event and other ClassPrepare events while this
> callback is executed.
> 358: // Sync with VMDeath event guards agains JVMTI_ERROR WRONG_PHASE.
Suggestion:
// Sync with VMDeath event guards agains JVMTI_ERROR_WRONG_PHASE.
test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/libAllowedFunctions.c
line 359:
> 357: // Block VMDeath event and other ClassPrepare events while this
> callback is executed.
> 358: // Sync with VMDeath event guards agains JVMTI_ERROR WRONG_PHASE.
> 359: err = (*jvmti)->RawMonitorEnter(jvmti, event_mon);
I don't see how this fixes the problem. You can be exiting VMDeath when this
monitor is entered. This does not block the get_thread_local() call below,
which is what leads to the WRONG_PHASE. I think using a raw monitor is the
right approach, but I was expecting to see VMDeath set a flag after grabbing
the monitor that indicated VMDeath had been called. Then ClassPrepare should
check this flag after grabbing the monitor and ignore the event if it is set.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20397#discussion_r1700920905
PR Review Comment: https://git.openjdk.org/jdk/pull/20397#discussion_r1700920369
