On Thu, 9 Apr 2026 21:12:00 GMT, Leonid Mesnik <[email protected]> wrote:
>> This is a bug in recompute enabled for thread filtered events. It doesn't >> check current jvmti phase. >> >> Usually it works fine because most of thread filtered events are not "truly" >> enabled before live phase. >> So `JvmtiEventControllerPrivate::recompute_enabled()` doesn't create state >> for them and thus doesn't call `recompute_thread_enabled` and never try to >> enable singestep event (and other thread filtered events). >> >> >> The issue happens when SingleStep event is enabled before live phase and >> also one of thread filtered and early events are enabled before live phase. >> >> I updated test to trigger this problem by itself. Also I simplified it to >> fail earlier and fail after VM Death. >> >> Aslo, verified with reproducer from >> https://bugs.openjdk.org/browse/JDK-6357005 >> by running test with async-profiler. >> >> Testing ther svc testing from tier5. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision: > > removed unused code I've posted one suggestion. Otherwise, this change looks good to me. src/hotspot/share/prims/jvmtiEventController.cpp line 529: > 527: > 528: julong was_enabled = ets->event_enable()->_event_enabled.get_bits(); > 529: julong now_enabled = THREAD_FILTERED_EVENT_BITS & Use of `julong` is inconsistent with other places where jlong is used. Also, it is not really needed for this fix. I'd suggest to separate it into another RFE to make a consistent use of julong for event mask bits. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/30617#pullrequestreview-4088013404 PR Review Comment: https://git.openjdk.org/jdk/pull/30617#discussion_r3062759249
