On Wed, 29 Oct 2025 04:31:16 GMT, David Holmes <[email protected]> wrote:
> > 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? That question has been on the table at least the past ten years, possibly longer, for those other threads I mentioned (as well as the Sweeper thread that I removed) and I have personally advocated for it at times. There could be JVM internal threads that are not JavaThreads because they do not run Java code, but share capabilities such as being part of the cooperative safepoint synchronization protocol, having TLABs, fast barriers, responding to thread-local handshakes, etc. The way such such JVM threads are modelled today is that they are JavaThreads that return true in is_hidden_to_external_view() to make them hidden from JVMTI. As Serguei pointed out earlier, the way that check is used in JVMTI could be more consistent, and we should make it more so. While I would welcome changing the way we model our JVM internal threads, I thought that this object streaming JEP is probably not the right place for such a wide refactoring. Such a change would presumably go through our inventory of JVM internal JavaThreads that are hidden to JVMTI and don't execute Java code, and find a better abstraction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2471827479
