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
