RFR: 8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112 [v2]
Serguei Spitsyn
sspitsyn at openjdk.org
Sat Aug 3 03:18:09 UTC 2024
On Sat, 3 Aug 2024 00:30:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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
More information about the serviceability-dev
mailing list