<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Btw, I had a chance to check out Helidon 4.0 and the results are mixed. I really like the programming model.<div class=""><br class=""></div><div class="">In a very simple (and probably not very meaningful nor scientific) test <a href="http://github.com/robaho/httpserver" class="">github.com/robaho/httpserver</a> outperforms it by 2x. I couldn’t get it to work on Linux (see <a href="https://github.com/helidon-io/helidon/issues/7983" class="">https://github.com/helidon-io/helidon/issues/7983</a>), which is strange given that they have very similar non-async designs.</div><div class=""><br class=""></div><div class="">The robaho httpserver achieves more than 6GB/sec on Linux under the same conditions as reported in the issue. Hopefully the Helidon team checks it out and makes some recommendations or at least provides reasoning around the performance issues.</div><div class=""><br class=""></div><div class="">Hopefully projects like this signal the days of Java async are over. Finally back to the model that made Java so successful in the first place.</div><div class=""><br class=""></div><div class="">Awesome work Loom team!<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2023, at 4:05 AM, Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" class="">Alan.Bateman@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div class="">
On 01/11/2023 20:13, Ilya Starchenko wrote:<br class="">
<blockquote type="cite" cite="mid:CAD0tGQssvaJK4k9qN8dpCZHRHS=VXW=8wcLLWbZbGBRwbd1OSA@mail.gmail.com" class="">
:
<div dir="ltr" class=""><div style="margin: 0px; font-style: normal; font-variant-caps: normal; font-stretch: normal; font-size: 12px; line-height: normal; font-family: "Helvetica Neue"; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-feature-settings: normal; min-height: 14px;" class=""><br class="">
</div><div style="margin: 0px; font-style: normal; font-variant-caps: normal; font-stretch: normal; font-size: 12px; line-height: normal; font-family: "Helvetica Neue"; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-feature-settings: normal;" class="">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)</div><div style="margin: 0px; font-style: normal; font-variant-caps: normal; font-stretch: normal; font-size: 12px; line-height: normal; font-family: "Helvetica Neue"; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-feature-settings: normal; min-height: 14px;" class=""><br class="">
</div><div style="margin: 0px; font-style: normal; font-variant-caps: normal; font-stretch: normal; font-size: 12px; line-height: normal; font-family: "Helvetica Neue"; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-feature-settings: normal;" class="">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?</div><div style="margin: 0px; font-style: normal; font-variant-caps: normal; font-stretch: normal; font-size: 12px; line-height: normal; font-family: "Helvetica Neue"; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-feature-settings: normal; min-height: 14px;" class=""><br class="">
</div><div style="margin: 0px; font-style: normal; font-variant-caps: normal; font-stretch: normal; font-size: 12px; line-height: normal; font-family: "Helvetica Neue"; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-feature-settings: normal;" class="">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.</div>
<br class="">
</div>
</blockquote>
In this mode, the read and write pollers do not block wait for
events. If there are no events then a poller will register with the
master poller and park. So think of the master poller as the lender
of last resort.<br class="">
<br class="">
I think you may have missed that unparking queues the virtual thread
to continue on the same carrier that the poller is mounted on. The
poller yields so queues itself to continue on the same carrier. In a
busy system this works quite well, less so when less busy as
stealing may mean the virtual thread and poller move to other
carriers.<br class="">
<br class="">
-Alan<br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>