On Wed, 18 Mar 2026 18:59:05 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) > > Zhengyu Gu has updated the pull request incrementally with one additional > commit since the last revision: > > @kevinjwalls' comment Okay. test/hotspot/jtreg/serviceability/threads/ThreadInfoTest.java line 97: > 95: } > 96: i++; > 97: } Nit: this could also just be a plain for-loop. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/30105#pullrequestreview-3971750164 PR Review Comment: https://git.openjdk.org/jdk/pull/30105#discussion_r2957003481
