RFR: 8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112 [v2]

[Serguei Spitsyn]

On Fri, 2 Aug 2024 23:05:36 GMT, Chris Plummer <cjplummer at openjdk.org> 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