Request for Custom Carrier Thread Group Support in Project Loom

[robert engels]

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 <ebubevm at 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250824/aa831229/attachment.htm>