On Fri, 2 Aug 2024 23:05:36 GMT, Chris Plummer <[email protected]> wrote:
>> 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.
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20397#discussion_r1702418344
