RFR: 8355631: The events might be generated after VM_DEATH event

[Stefan Karlsson]

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3345735398