Request for Custom Carrier Thread Group Support in Project Loom

[Victor Madu]

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/20250720/fd0dc6af/attachment.htm>