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