On Sat, 3 Aug 2024 00:30:55 GMT, Serguei Spitsyn <[email protected]> wrote:
>> 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.
>
> Thanks, Chris.
> The `JvmtiExport::post_vm_death()` posts the `VMDeath` before changing the
> phase to `JVMTI_PHASE_DEAD`.
> The `VMDeath` callback is blocked on the `RawMonitor` while it is grabbed by
> the `ClassPrepare` event callback.
> But you are right, there is a sync gap in `JvmtiExport::post_vm_death()`
> between the `VMDeath` callback execution and phase changing. So, I'll go with
> your suggestion and introduce a flag.
Added `is_vm_dead` flag.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20397#discussion_r1702441824
