On Mon, 29 Sep 2025 08:45:05 GMT, Stefan Karlsson <[email protected]> wrote:
>> The JVMTI spec says: >> https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath >> `The VM death event notifies the agent of the termination of the VM. No >> events will occur after the VMDeath event.` >> >> However, current implementation changes state and only after this start >> disabling events. >> >> It might be not a conformance issue, because there is no way to get thread >> state in the very beginning of event. >> The main practical issue is that currently certain events are generated when >> VM is becoming dead. So any function in event should check error against >> JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled >> https://bugs.openjdk.org/browse/JDK-8352654 >> >> The proposed fix to disable all event generation and then post the last >> (VMDeath) event. After this event is completed change VM phase to death. >> It's guaranteed that no any events are generated after VMDeath completion. >> >> After this fix the VMDeath callback also can't generate any events. >> The alternative is to disable events posting after VMDeath completion and >> before changing VM state. However, seems it is still a gap between vm death >> event completion and disabling events. So user can see events after VMDeath >> completion. >> >> It might be still possible also to wait while all currently executing >> events are completed. It is not required be specification, might add >> unneeded complexity. So I want to apply this fix first and then to check if >> we still any problems. >> Then, I plan to wait with timeout until all current (and queued) jvmti >> events are completed with some reasonable timeout. >> Currently, I haven't seen problems with this fix and >> https://bugs.openjdk.org/browse/JDK-8352654. > > Hi Leonid, > > We currently have a shutdown issue where the GC is shut down before the last > JVMTI events are sent from the same thread. The problem is that the JVMTI > code allocates Java objects, which is problematic given that we've just shut > down the GC threads. > > Because of this extra allocation we have added a stop-gap solution that is > not what we want long-term, but it fixes some reoccuring issue that was > reported. The real solution involves switching the order between shutting > down the GC threads and sending the last JVMTI event. > > Take a look at before_exit in java.cpp: > > // Run before exit and then stop concurrent GC threads > Universe::before_exit(); > > ... // some unrelated code ... > > if (JvmtiExport::should_post_thread_life()) { > JvmtiExport::post_thread_end(thread); > } > > // Always call even when there are not JVMTI environments yet, since > environments > // may be attached late and JVMTI must track phases of VM execution > JvmtiExport::post_vm_death(); > JvmtiAgentList::unload_agents(); > > > The GC team thinks that the thread that shuts down the GC threads should not > call code that allocates, so we would like to hoist the JVMTI code to before > the code that stops the GC threads > > ... // some unrelated code ... > > if (JvmtiExport::should_post_thread_life()) { > JvmtiExport::post_thread_end(thread); > } > > // Always call even when there are not JVMTI environments yet, since > environments > // may be attached late and JVMTI must track phases of VM execution > JvmtiExport::post_vm_death(); > JvmtiAgentList::unload_agents(); > > // Run before exit and then stop concurrent GC threads > Universe::before_exit(); > > > There's a JBS entry created for the issue described above: > https://bugs.openjdk.org/browse/JDK-8367902 > > Given that you have looked into this VMDeath code and proposes a change to > it, maybe you could help reasoning about if the above reordering would fit > into what you proposes here in this PR? @stefank : > Given that you have looked into this VMDeath code and proposes a change to > it, maybe you could help reasoning about if the above reordering would fit > into what you proposes here in this PR? @lmesnik : > The VM Death call back is still valid point to call any java code. So the GC > should be active at this point. I quickly check that > 'Universe::before_exit()' doesn't post any jvmti events, so it makes sense to > call it after vm death. Stefan, I agree with Leonid that your reordering suggestion is reasonable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3354166387
