On Wed, 3 Jun 2026 14:16:19 GMT, Per Minborg <[email protected]> wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 401: >> >>> 399: */ >>> 400: @Stable >>> 401: private AutoCloseable confinedArenaAllocator; >> >> I'm on the fence about this—adding a new field into Thread (which also means >> for all Virtual Threads that get allocated) for a very specific >> use-case—what other options exist, and do VirtualThreads need their own >> caches or can they rely on the caches of their carriers? > > Experiments with carrier-local caches reveal that it is more memory > efficient, but very complex and slow. A virtual thread can be remounted on > another carrier, for example, which creates problems. > > For platform threads, I do not believe an extra field is a problem. Creating > such a thread is resource-intensive anyhow, and an extra field is well into > the noise. > > For virtual threads, I am a bit uncertain how such a thread is "parked". If > one creates a million virtual threads, then we typically would need an extra > 4 MiB if no pools are ever created (just field overhead). There are already > a large number of fields in Thread/LocalThread. > > Using a ThreadLocal is much slower. The challenge is that it is a tragedy of the commons-kind of situation, if every possible use cases reasons the same then it is 4MB * use-cases for adding fields to Thread. Given that this use-case is rather niche in terms of "how many threads will over the course of their lifetime make use of this field". I may be that my calibration is off here, so I'm inviting @AlanBateman to the chat to do a sanity-check on me :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31365#discussion_r3349272402
