java.lang.ThreadBuilders and java.lang.ThreadBuilders.newVirtualThread() are not public

[Alan Bateman]

On 21/08/2024 09:13, Rick Hendricksen wrote:
>
> Hi Alan,
>
> Thanks for taking the time to help us with this issue.
>
> We see three problems with using the default scheduler with maxPoolSize:
>
>   * Other virtual threads which are not directly related to the
>     simulation would slow down the simulation
>   * Running multiple simulations in parallel would not be possible
>
In that case, parallelism means several VMs, each running with 
maxPoolSize=1, rather than running several simulations in the same VM at 
the same time.


>
>   * We need full control over which thread runs, and how to treat
>     yield. If the thread is yielding because of a simulation-related
>     blocking operation, we want to run the next thread. If it’s
>     yielding due to IO, we don’t want to switch to another thread. If
>     IO wait would result in a yield, that would be unpredictable, and
>     would affect the result of our simulation.
>
> It would be very helpful for us if custom schedulers would be exposed. 
> Could you tell us more about the explorations you mentioned? And is it 
> an option to take our use case into account there?
>
>
There are two explorations at this time. One is allowing the scheduler 
be selected at virtual Thread create time, like the prototype API on the 
builder that was in EA builds for a long time but didn't get any 
feedback. One of the use-cases for this is servers that want to use 
their own event loop thread as a carrier to avoid hand-off. The other 
exploration is exposing a way to replace the system-wide scheduler for 
servers that want to manage their own thread pool rather than use a work 
stealing scheduler. We talked about this a bit at JVMLS 2024, I think 
the recordings will be posted soon.

Note that the problem space and the possible interface for custom 
schedulers is larger than might initially seem. You touched on exposing 
the "reason" for preemption and that is one of several things that a 
scheduler may need to be notified of. One thing that would be useful to 
know from your experiments is how you distinguish between your 
"simulation-related blocking operation" and the dozens of other possible 
cases where a thread may be preempted.

In any case, the summary on this topic is that it is being explored 
again but proceeding with great caution.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240821/4af4d29f/attachment.htm>