On Tue, 30 Sep 2025 06:28:15 GMT, David Holmes <[email protected]> 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
