On Wed, 3 Jun 2026 14:26:03 GMT, Viktor Klang <[email protected]> wrote:
>> 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 :) Whether this field increases the size of `Thread` objects also depends on the alignment and size of all existing `Thread` fields (both normal **Java** and **VM**‑injected) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31365#discussion_r3354199124
