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

[David Holmes]

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

src/hotspot/share/prims/jvmtiEventController.cpp line 1060:

> 1058: void
> 1059: JvmtiEventControllerPrivate::vm_death() {
> 1060:   _execution_finished = true;

Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic<T>`). You are still racing with others threads but this would at least attempt to minimise the window.

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

PR Review: https://git.openjdk.org/jdk/pull/27504#pullrequestreview-3282743437
PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2389970167