On Tue, 16 Sep 2025 19:11:49 GMT, Leonid Mesnik <[email protected]> wrote:
>> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to >> access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by >> tests. I found it using jtreg test thread virtual factory plugin. I updated >> existing test to reproduce this problem. The easiest way is to suspend >> current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is >> required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision: > > ident fixed Thanks for finding and fixing this Leonid. src/hotspot/share/runtime/suspendResumeManager.cpp line 89: > 87: int64_t id = java_lang_Thread::thread_id(_target->vthread()); > 88: ThreadBlockInVM tbivm(current); > 89: MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag); Transitioning to the blocked state and acquiring the monitor should still be executed without JVMTI included. We won’t see any issues today because suspend/resume is only used by JVMTI code. src/hotspot/share/runtime/suspendResumeManager.cpp line 105: > 103: // If target is the current thread we can bypass the handshake > machinery > 104: // and just suspend directly > 105: self_suspend(register_vthread_SR, self); Since `self_suspend()` is a very short method and only called from here, I would keep the method as it was and if anything define `set_suspended_with_id(int64_t id, bool register_vthread_SR)` instead. ------------- PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3231325205 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353407110 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353410713
