On Sat, 10 Oct 2026 07:09:41 GMT, Yunbo Zhang <[email protected]> wrote:
> Please review this small fix. > > `SetExtensionEventCallback()` registers the callback but does not enable the > event. > > **Fix:** > > Update the user-enabled bit when setting or clearing the callback, and add > mount/unmount protection when updating the event state. > > **Testing:** > > - Removed explicit mount/unmount enabling from `libVThreadEventTest.cpp` to > verify that callback registration enables the events. > - In `libMethodExitTest.cpp`, disable these events after registration, since > the test enables them per thread at the second breakpoint. > - `serviceability/jvmti`: 264 passed, 0 failed. > - `vmTestbase/nsk/jvmti`: 586 passed, 0 failed. > > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Thank you for taking care about this issue. However, I'd prefer to go in an opposite direction and align the extension events behavior with normal events. I'll file a separate enhancement to get rid of this spec wording: `... and enables the event. Or, if the callback is null, disables the event. Note that unlike standard events, setting the callback and enabling the event are a single operation.` This approach will cause a minor compatibility issue, of course. But it is important to achieve a symmetry with normal events here and get rid of unneeded complexity. Just a note about your fix... It is correct in general. However, it is over-passing the capability checks which SetEventNotificationMode has (e.g.`can_support_virtual_threads` cpability for `VirtualThreadMount`/`VirtualThreadUnmount` extension events). Please, let me know about your opinion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33295#issuecomment-6165474253
