On Tue, 28 Oct 2025 08:53:35 GMT, Erik Österlund <[email protected]> wrote:
>> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 483: >> >>> 481: assert(t != nullptr, "invariant"); >>> 482: oop threadObj = t->threadObj(); >>> 483: return threadObj != nullptr ? AccessThreadTraceId::id(threadObj) : >>> static_cast<traceid>(t->monitor_owner_id()); >> >> Is this related to JEP? >> Is it bug fix (return `monitor_owner_id` instead of 0)? > > I added this because the AOT thread starts earlier than the Thread class is > initialized. Therefore, I have to create the thread with a null thread > object, and initialize the thread oop after the Thread class is initialized. > This threw this JFR code off. So I made it accept the monitor_owner_id which > is set up for similar reasons. Drive-by comment - I have not looked at the PR but this exchange caught my attention. This sounds a little off. If this is a `JavaThread` then it presumably runs Java code. But it can't run Java code without having an associated `java.lang.Thread` object to be the "current thread". So what exactly is it doing this early in the VM init process that allows it not to have a "current thread" representation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2468603747
