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 I think the problem is the moving of jlong java_tid = java_lang_Thread::thread_id(tobj); to after the `MutexLocker` - we now have an unhandled oop and the mutex acquisition could safepoint. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30105#issuecomment-4093946329
