Performance Questions and Poller Implementation in Project Loom

[Ilya Starchenko]

 On 1 Nov 2023 at 00:44:26, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> This code is significantly replaced in the fibers branch of the loom repo.
> We have a draft PR to bring this into the main line for JDK 22. The main
> difference is that the number of epoll instances is based on the number of
> hardware threads, actually the closest power of 2, with a virtual thread
> per instance.


Alan,

Thank you for your response. I've taken a look at the JDK 22 fibers branch,
and I have a few more questions that I hope you can help me with.


Firstly, with the ReadPoller and WritePoller now being based on the number
of hardware threads, could you please clarify the MasterPoller is used to
make the polling mechanism non-blocking as well?(there's no events, so we
park)


Secondly, from what I can gather, the Poller itself is used only to polling
events(obviously) and park/depark vthread. However, the actual reading from
buffers and writing to the OS buffer is performed by the virtual threads
themselves, which can be executed by any platform thread. There is no
performance lack in this case, because we kinda losing data locality(due to
virtual threads being carried by any platform thread without affinity)?
Have you considered to make all network operations to the platform thread
and reserving virtual threads solely for user code execution when data is
ready?


I apologize if I've misunderstood any aspects of the architecture, and I'm
genuinely trying to gain a better understanding of how it all works.


- Ilya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231101/1bc31a0b/attachment-0001.htm>