On Tue, 28 Oct 2025 09:52:21 GMT, Erik Österlund <[email protected]> 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
