RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v10]

[David Holmes]

On Tue, 28 Oct 2025 08:53:35 GMT, Erik Österlund <eosterlund at openjdk.org> 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