On Tue, 28 Oct 2025 09:07:08 GMT, David Holmes <[email protected]> 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
