On Fri, 2 Aug 2024 20:34:01 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
>
> Serguei Spitsyn has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - fix typo in a comment
> - corrections in test ClassPrepare event handler
test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/libAllowedFunctions.c
line 363:
> 361: get_phase(jvmti, &phase);
> 362: if (phase != JVMTI_PHASE_START && phase != JVMTI_PHASE_LIVE) {
> 363: if (phase != JVMTI_PHASE_DEAD) {
After this check is made, what prevents JVMTI from moving to the
JVMTI_PHASE_DEAD before the get_cur_thread() call below? I'm not sure if the
phase is changed to JVMTI_PHASE_DEAD before or after calling VMDeath, but it
seems in either case you can end up with the phase changing after making this
check. There is nothing that stops the phase from changing while holding the
raw monitor.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20397#discussion_r1702388142
