On Fri, 6 Mar 2026 02:35:04 GMT, Zhengyu Gu <[email protected]> wrote:
> Please review this change that fixes crashes by jmm_GetThreadInfo() call. > > There are several issues: > - ThreadIdTable::lazy_initialize() has typical double-checked locking pattern > without proper memory barrier, that may result in uninitialized/partial > initialized table to be observed by other threads. Added release/acquire > barrier to address this issue. > - Query ThreadIdTable can race add/remove thread operations. In short, the > thread returned from the query may be freed. Fortunately, > jmm_GetThreadInfo() acquires stable thread list before query, so we only need > to make sure that returned thread is in the list (checking > thread->is_exiting() does not help due to the race) > - I moved thread Id insertion code from ThreadSMR to Threads, to be symmetric > to thread Id removal code. > > Tests: > - [x] Tier1 on Linux and MacOSX (fastdebug) > (`tools/javac/annotations/typeAnnotations/IncorrectCastOffsetTest.java` > failure seems unrelated, it also fails in master) This pull request has now been integrated. Changeset: 4e9b35f9 Author: Zhengyu Gu <[email protected]> URL: https://git.openjdk.org/jdk/commit/4e9b35f9e8771e18352c7dfd3e3bc85f1811f617 Stats: 215 lines in 6 files changed: 196 ins; 2 del; 17 mod 8323792: ThreadSnapshot::initialize can cause assert in Thread::check_for_dangling_thread_pointer (possibility of dangling Thread pointer) Co-authored-by: Kevin Walls <[email protected]> Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/30105
