<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">For some further data points. Using VthreadTest <a href="https://github.com/robaho/vthread_test" class="">here</a> (essentially a message passing system):<div class=""><br class=""></div><div class="">With 32 producers, 32 consumers, 500k messages on an 4/8 core machine:</div><div class=""><br class=""></div><div class="">1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds</div><div class="">1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds</div><div class="">2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds</div><div class="">2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds</div><div class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds</div></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">(ABQ is stdlib ArrayBlockingQueue)</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am “fairly cetain” the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound “do nothing” test that allocates no objects still uses more than 25% system cpu - which seems odd).</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Here is a async profile capture of 3b:</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><img apple-inline="yes" id="DA5D9975-772E-4B78-AA2A-1C9A62D9AE78" width="640" height="208" src="cid:CE85336B-FD0B-40A9-9616-4944823FCAAC" class=""></div><div class=""><br class=""></div><div class="">Notice that the vast majority of the time is used in internal context switching.</div><div class=""><br class=""></div><div class="">I can “fairly agree” with the project’s stated bias towards server systems with 1000’s of threads (I do think 1000’s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well.</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2023, at 4:16 PM, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" class="">ron.pressler@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On 3 Jan 2023, at 19:24, thurston N <<a href="mailto:thurston.nomagicsoftware@gmail.com" class="">thurston.nomagicsoftware@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hello Ron,</div><div class=""><br class=""></div><div class="">Quoting:<br class=""><pre class="">"Virtual threads replace <b class="">short </b>individual *tasks* in your application, not platform threads."<br class=""><br class=""></pre><pre class=""> Why <b class="">short?<br class=""><br class=""></b></pre><pre class=""><b class="">Take a TCP server's accept loop. I would have thought that's a natural target for execution in a virtual thread. <br class=""><br class=""></b></pre><pre class=""><b class="">And it's more or less intended to run forever.<br class=""></b></pre></div></div></div></blockquote><div class=""><br class=""></div>A small number of virtual threads may run for a long time, but the vast majority would be short lived. They would naturally form a hierarchy: you’d have one or a couple of threads accepting connections that live forever, several thousand request-handling threads that live as long as a single request, and then tens of thousands or more each servicing a single outgoing service request in a fanout, and those would be even shorter-lived.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><pre class=""><b class="">
"They are best thought of as a business logic entity representing a task rather than an “execution resource.”"<br class=""><br class=""></b></pre><pre class=""><b class="">That's a pretty good definition of an "actor" (as in actors-model). But there's no (even implicit) restriction on the duration of <br class=""></b></pre><pre class=""><b class="">an actor's lifetime.<br class=""></b></pre><pre class=""><b class="">Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs?</b></pre></div></div></div></blockquote><div class=""><br class=""></div>Threads are sequential task that is done concurrently with others. What protocols are used to communicate among threads (and the actor model is a communication protocol) is up to the programmer. An actor model is a bit too high-level for the JDK, but libraries may certainly offer actors based on virtual threads, just as others may build other high level constructs.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><pre class=""><b class=""> <br class=""></b></pre><pre class=""><b class="">I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al.<br class=""></b></pre><pre class=""><b class="">It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a <br class=""></b></pre><pre class=""><b class="">platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for)<br class=""></b></pre><pre class=""><b class="">And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them)<br class=""></b></pre><pre class=""><b class="">IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios
</b></pre></div></div></div></blockquote><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">My intent is not to restrict so much as to focus. Simulations are absolutely a great use-case for lightweight threads, but there are implementation choices that may need to balance some desirable properties with others and could result in virtual threads being a better fit for some use-cases than others. Because there are significantly more Java servers than Java simulations, and because servers are normally more complex (in terms of failure modes and architectural graph) and their developers are more mainstream and could benefit from more help, *if* there’s some prioritisation to be made, the server use-case is the one we prioritise over others by addressing it *first*. More people are interested in that use-case, that’s where virtual threads can contribute the most value, and that’s why it’s our *initial* focus.</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">— Ron</div></div></blockquote></div><br class=""></div></div></div></body></html>