
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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.<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Jul 20, 2025, at 5:29 AM, Victor Madu <ebubevm@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><p>Dear Loom Team,</p><p>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.</p><p>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 <code>Thread.ofVirtual().scheduler(...)</code>) or accessing the current carrier thread (e.g., <code>Thread.currentCarrierThread()</code>). I understand that this abstraction is intentional to preserve simplicity and portability.</p><p>That said, I’d like to propose a possible extension to the current model: the ability to define and manage <strong>multiple groups of carrier threads</strong>, which virtual threads can be scheduled onto. With such support, developers could:</p>

<ul>

<li><p>Spin up dedicated pools of carrier threads for different classes of virtual workloads (e.g., I/O-heavy vs CPU-heavy),</p>

</li>

<li><p>Pause/resume or assign priorities to these carrier groups,</p>

</li>

<li><p>Integrate carrier thread group control into custom runtime environments.</p>

</li>

</ul><p>This flexibility could enable advanced scenarios such as runtime observability, load isolation, resource throttling, or tighter integration in frameworks with custom concurrency policies.</p><p>For context, I attempted something like this using:</p>

<pre class="gmail-overflow-visible!"><div class="gmail-contain-inline-size gmail-rounded-2xl gmail-relative gmail-bg-token-sidebar-surface-primary"><div class="gmail-flex gmail-items-center gmail-text-token-text-secondary gmail-px-4 gmail-py-2 gmail-text-xs gmail-font-sans gmail-justify-between gmail-h-9 gmail-bg-token-sidebar-surface-primary gmail-select-none gmail-rounded-t-2xl"><br></div><div class="gmail-overflow-y-auto gmail-p-4" dir="ltr"><code class="gmail-whitespace-pre! gmail-language-java"><span class="gmail-hljs-type">ExecutorService</span> <span class="gmail-hljs-variable">carrierThreadPool</span> <span class="gmail-hljs-operator">=</span> Executors.newFixedThreadPool(...);

Thread.Builder.<span class="gmail-hljs-type">OfVirtual</span> <span class="gmail-hljs-variable">builder</span> <span class="gmail-hljs-operator">=</span> Thread.ofVirtual().scheduler(carrierThreadPool);

</code></div></div></pre><p>...only to find that the <code>.scheduler(...)</code> method is not available, and <code>currentCarrierThread()</code> is also inaccessible due to being non-public.</p><p>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.</p><p>Thanks again for the amazing work you’re doing and for considering this request.</p><p>Best regards,<br>

Victor Madu</p></div></div>

</div></blockquote></div><br></body></html>