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

[David Holmes]

On Tue, 28 Oct 2025 09:52:21 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

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

Sorry I should have said "run Java code and/or interact with oops" - though even that may be incomplete. Okay point taken though the others still get their Thread oop before they start. Having a new "JavaThread" running around before even the main thread is fully attached may surprise some code.

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

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