I think a natural extension to this would be a Java based “cpu affinity” management - combined with real time thread priorities for the carrier groups - it would simplify a lot of HPC infrastructure.
> On Jul 20, 2025, at 5:29 AM, Victor Madu <ebub...@gmail.com> wrote: > > Dear Loom Team, > > First, thank you for the incredible work on Project Loom. Virtual threads are > a game-changing feature that’s making concurrency in Java much more efficient > and scalable. > > While exploring virtual threads in JDK 21+, I noticed that there is currently > no public API for assigning a custom carrier thread pool (e.g., via > Thread.ofVirtual().scheduler(...)) or accessing the current carrier thread > (e.g., Thread.currentCarrierThread()). I understand that this abstraction is > intentional to preserve simplicity and portability. > > That said, I’d like to propose a possible extension to the current model: the > ability to define and manage multiple groups of carrier threads, which > virtual threads can be scheduled onto. With such support, developers could: > > Spin up dedicated pools of carrier threads for different classes of virtual > workloads (e.g., I/O-heavy vs CPU-heavy), > > Pause/resume or assign priorities to these carrier groups, > > Integrate carrier thread group control into custom runtime environments. > > This flexibility could enable advanced scenarios such as runtime > observability, load isolation, resource throttling, or tighter integration in > frameworks with custom concurrency policies. > > For context, I attempted something like this using: > > > ExecutorService carrierThreadPool = Executors.newFixedThreadPool(...); > Thread.Builder.OfVirtual builder = > Thread.ofVirtual().scheduler(carrierThreadPool); > ...only to find that the .scheduler(...) method is not available, and > currentCarrierThread() is also inaccessible due to being non-public. > > Are there any plans to support this level of carrier group configurability in > future versions of the JDK or Project Loom? Even an opt-in or expert-mode API > would go a long way in allowing more fine-tuned control for advanced users > without impacting the simplicity that Loom provides by default. > > Thanks again for the amazing work you’re doing and for considering this > request. > > Best regards, > Victor Madu >
