On Tue, 28 Oct 2025 16:07:59 GMT, Erik Österlund <[email protected]> wrote:
>> 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. > > The main thread still attaches first. The main thread, like this new AOT > thread, attaches before it has a thread oop. They both have their thread oops > created inside of Threads::initialize_java_lang_classes after the Thread > class has been initialized. I see that you have already found a number of places where the code does get surprised by this and so need to check explicitly for it being the AOT thread. You say: > It is a JavaThread because I want it to have a TLAB But I am not sure what you mean by that. IIUC this thread will be responsible for creating objects in the heap based on the AOTCache contents so you want that to be efficient. But this doesn't really seem to be a JavaThread and you are now having to special case code in a number of places both because of the initial null-JLT-oop and because you don't want things like JVMTI to even see this thread exists. Is it possible to define a NJT that can still allocate in the heap the way you need? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2471699437
