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

Leonid Mesnik lmesnik at openjdk.org
Tue Sep 30 15:41:43 UTC 2025


On Tue, 30 Sep 2025 06:28:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > After this fix the VMDeath callback also can't generate any events.
> 
> I think this needs a CSR request and likely a release note. Though if you plan to later wait for all event processing to complete, is it even necessary to make the current change? The spec is very imprecise when it comes to when exactly no further events will be processed, but it seems reasonable to expect that the callback for VM_DEATH is the last thing that should generate events. Though unless event processing is fully synchronized with locks (which I'm pretty sure it isn't) then you have races no matter what you do. I am concerned that, given you cannot completely prevent events from being generated "after" VM_DEATH, the change may "break" more code than it "fixes". ??

This change completely prevents generation of events after VM Death is posted. While the callback execution is might be in the progress. I plan to fix this later. The main problem would be dealing with long-processing events in daemon threads. 

Right now I am not sure if CSR is needed. The new  behaviour doesn't require specification changes. I want to implement this fix separately to ensure that it doesn't break anything.  Then I plan to add synchronization separately. This fix also doesn't change specification, because spec is very 'imprecise' as you mentioned.  
It might be makes sense to amend specification saying explicitly that VM Death is the last event generated in the VM. But is it  needed?

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

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


More information about the hotspot-dev mailing list