Cache topology aware scheduling

[Alan Bateman]

On 04/10/2024 08:31, Danny Thomas wrote:
> I’d wondered about the external submit changes; I’ll take your word 
> for it :)
>
> Does seem that if you do expose an API, you’d want to differentiate 
> things such as unpark/yield from other submissions.
>
> I guess there’s also pathological cases where a VT is primarily 
> driving creation of virtual threads in an application. I’ve tried a 
> few heuristics for deciding when to externally submit instead of 
> locally submitting to a FJP, and I found it difficult to avoid 
> prematurely and ineffectively moving work; but I am working with 
> purposefully contrived benchmarks right now, rather than something 
> that looks like a real application.

Virtual threads unparking other virtual threads will be common, anything 
CSP like, or using locks that are contended, means the custom 
scheduler's execute method will be called in the context of a virtual 
thread that is unparking another virtual thread.

Very application dependent as to whether you'll see virtual threads 
starting other virtual threads. A web server where the listener is a 
platform thread may start a virtual thread for each connection, not too 
interesting. However, anything using structured concurrency where there 
the tree goes beyond a single level will lead to virtual threads forking 
new virtual threads.

I don't think we are close to exposing any API at this point. There is 
list of possible things that could be interesting but it's a big step to 
commit to an interface.

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