Scheduler API Feedback

[Alan Bateman]

On 04/10/2025 14:19, dreamlike_ocean lei wrote:
>
> Hello @loom-dev <loom-dev at openjdk.org <http://openjdk.org>>,
>
> I have been enjoying the new POLLER_PER_CARRIER design in the Loom 
> repo and I really like the direction it is going.
> While building on top of the latest code, I noticed a couple of issues 
> and would like to ask for clarification.
>
Thanks for your mail. It's useful to hear from folks that are trying out 
the experimental support for custom schedulers in the loom repo as this 
will help to inform whether any of the directions prototyped should be 
taken further.

BTW: I assume "dreamlike_ocean lei" isn't your real name. It would be 
helpful to use a real name or affiliation so we have some idea who you are.

> 1.
>
>     When calling |Thread.startVirtualThread|, the new virtual thread
>     does not inherit the scheduler of the calling virtual thread, but
>     instead uses |DEFAULT_SCHEDULER|. What is the reasoning behind
>     this design? Could there be a mechanism to allow implicit
>     inheritance? This would be very helpful for custom schedulers
>     based on the per-core model.
>
In a system with several virtual thread schedulers in use, which I think 
is what you mean, then it would be unpredictable and problematic to 
inherit the scheduler in many cases. If some library were, on first 
usage, start a virtual thread as a "background thread" that runs 
indefinitely then inheritance would mean it depends on the first usage. 
Examples where inheritance at thread create time is problematic are the 
thread context class loader, and until recently, the inherited access 
control context.

When you say "custom schedulers based on the per-core model" do you mean 
you are experimenting with a scheduler per core in order to get "carrier 
affinity"  (virtual thread X will always be scheduled on carrier Y). You 
might also be using processor affinity to bind carrier Y to specific 
sets of CPUs.

You might find it simpler to just use one scheduler and keep a mapping 
of virtual thread to carrier. That would remove complications with 
lifecycle that would arise if carriers were to terminate (e.g. 
idle/keep-alive). It might avoid needing to expose APIs to get a virtual 
thread's scheduler, which I think what your second point is about.

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