<div dir="ltr">After quite a bit of experimentation, I can at least say that last level cache aware task placement on 4th Generation EPYC (Genoa) is a real boon. I generalised my original approach, because it doesn't involve customizing the nodes-per-socket setting (which we can't do on AWS anyway, NPS = 1), introduce the risks/complexity of processor isolation and per-thread affinity, or make the scheduler's life too difficult:<br><br><a href="https://github.com/DanielThomas/virtual-threads-cluster-aware/blob/main/src/main/java/com/netflix/sandbox/ClusteredExecutors.java">https://github.com/DanielThomas/virtual-threads-cluster-aware/blob/main/src/main/java/com/netflix/sandbox/ClusteredExecutors.java</a><br><br>With virtual-to-virtual-thread submissions and particularly structured concurrency providing a heuristic for locality, I'm convinced there's a significant opportunity here. I've still got some more real world experiments to run, but will get a TechBlog post up when I have something to share.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 14, 2024 at 2:35 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/09/2024 04:55, Danny Thomas wrote:<br>
> Even with 10s of thousands of tasks queued, it looks like it's more <br>
> than fast enough as a heuristic. I'm now doing a choice of two, with <br>
> the current processor's pool being the preferred choice. For the <br>
> simple external submit, starting a virtual thread that spawns another <br>
> sharing data, I see up to a 25% improvement in throughput (pleasingly, <br>
> the default scheduler occasionally accidentally lands workers close to <br>
> each other and comes within a few percent).<br>
><br>
> I think we want to be as sticky as we can to the current <br>
> worker/cluster, so ForkJoinWorkerThread.hasKnownQueuedWork is probably <br>
> too conservative as a heuristic, but thanks for the heads up.<br>
><br>
> Have you gotten as far as thinking about how yielding and compensation <br>
> will be exposed?<br>
<br>
I think the experiment that Francesco may be based on the prototype <br>
VirtualThreadTask interface that we had temporarily exposed in EA builds <br>
some time ago. That gave the mapping of task to virtual Thread that thus <br>
thread state and park blocker when yielding.<br>
<br>
There isn't much need for compensating right now, at least not since the <br>
changes to Object.wait to preempt when waiting. There is still a need to <br>
support reverse DNS lookups but that has an SPI now [1] so a different <br>
resolver can be deployed if needed.<br>
<br>
As to your question, then this project hasn't decided whether to expose <br>
anything. There at least 3 exploration efforts going on right now, two <br>
with implClass, the other (I think) with prototype API, and we want to <br>
see what we can learn from these experiments.<br>
<br>
-Alan<br>
<br>
[1] <a href="https://openjdk.org/jeps/418" rel="noreferrer" target="_blank">https://openjdk.org/jeps/418</a><br>
</blockquote></div>