On Thu, 4 Jun 2026 07:18:38 GMT, ExE Boss <[email protected]> wrote: >> 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)
The options here are: 1. do what this PR does -- treat all threads the same. 2. don't use any pooling if allocation request comes from a VT. 3. when request comes from VT, use the pool of the carrier 1 and 2 are simple, but have the usual drawbacks. The former adds some footprint for every thread doing native allocation. The latter simply refuses to play ball with VTs. Option 3 is attractive, and probably not overly complex. But it does mean that some threads/arenas do not _own_ the pool, so the cleanup has to take that into account. And, the virtual thread "migrating" to different VTs is a real issue (but if we detect migration we might simply fallback to a standard allocation). In general, I think there's an non-zero chance that if a thread uses off heap memory it might get pinned (e.g. because it does a downcall). So I don't think the scaling requirement for this particular use case are as extreme as in other use cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31365#discussion_r3380901734
