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

[Erik Österlund]

On Tue, 28 Oct 2025 09:07:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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?

We have loads of JavaThreads that don't run Java code (e.g. service thread, compiler threads, string dedup thread, monitor deflation thread). The window of time in which it lacks a Thread object, is before we start executing Java byte codes at all. But like those other threads I mentioned, it does not have any business executing Java code, despite being a JavaThread. It is a JavaThread because I want it to have a TLAB so it can efficiently allocate objects in the heap.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2468791574