On 09/10/2025 22:11, Man Cao wrote:
Hi loom developers,
Official support for custom schedulers is highly valuable to some of
our Java applications such as our colleague David Gay's use case.
Are there any major concerns or obstacles to official support for
custom schedulers?
There are some workloads that are not suited to a work stealing
scheduler. We've seen this with workloads that have low concurrency, not
a lot going on, and the scanning to "find work" consuming additional CPU
cycles that nobody wants to pay for. There may be merit in having the
JDK provide a different scheduler for such cases, more experimentation
is required.
There are folks that want to do things like using the AWT event thread,
or the JavaFX application thread, as the carrier. They've seen
coroutines used on UI threads in other systems and want to experiment
doing something similar. Early explorations into this did not go very far.
There are other folks that are interested in thread affinity, binding
virtual threads to specific carriers, and carriers to specific cores in
NUMA nodes. Some of this exploration is about integration with existing
systems that use event loops. We are looking forward to a write-up of
these explorations and any findings.
Beyond this there are folks doing fun things with simulation and other
experimentation.
I'm not familiar with David Gay's work except for Liam's mail to say
that they are doing something in the area of multi-tenancy. If a
write-up or a summary of the explorations and findings could be sent to
loom-dev then it would be useful.
To your question, the topic of custom schedulers is an
exploration/research topic. The JDK has to be cautious. Calling out to a
custom scheduler (= arbitrary code) from core/sensitive parts of the
runtime is very scary. It's very easy to "self deadlock" - we've seen
folks trying to use locks to coordinate between mounted virtual threads
and their carrier. We are also concerned that the API surface for
schedulers will grow.
There are two prototypes in the loom repo at this time, this is what
Liam linked to. We are hoping that folks that are interested in this
topic will try one or both and come back their findings. The more data,
esp. from real world usage, will help inform this project on whether
there is merit is going further with either direction or whether there
are other directions that might be more fruitful.
-Alan
