<div dir="auto">I am not a Loom developer, so can't speak of what should be supported.<div dir="auto"><br></div><div dir="auto">RingBuffer as written there is not synchronized correctly and can lead to hangs even if you assume the behaviour of Thread.yield is fair. I won't go into detail, but the producers not synchronizing between themselves leads to hangs.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Alex</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Dec 2022, 04:31 robert engels, <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">OK. I created a stand-alone test case that demonstrates the problem. It is available at <a href="https://github.com/robaho/vthread_test" target="_blank" rel="noreferrer">https://github.com/robaho/vthread_test</a><div><br></div><div>If you run VThreadTest 8 8 1000000 (at least on my 4 core iMac), eventually the VThreadTest native thread will ‘spin’ attempting to unpark() a virtual thread (and have it read from the queue). If you use the debugger you see that the the vthread it is attempting to unpark is unparked - it has a run state=2 and runPermit=true but it never runs - leading to the VThreadTest thread to spin indefinitely.</div><div><br></div><div>The reason is the 8 producers are “spinning” as well, trying to put into the main queue. This means that the ‘consumer’ vthread can never run to pull an item from the queue to allow the main to make progress.</div><div><br></div><div>Adding a Thread.yield() to the spinning put() does not help.</div><div><br></div><div>Adding a LockSupport.parkNanos(1) to the spinning put() allows it to work.</div><div><br></div><div>I think Thread.yield() is broken in this regard. I know that Thread.yield() is documented to be advisory only, but if there is no virtual thread preemption a lot of code is going to require extra effort and testing to port to virtual threads. Developers expect “fair” thread scheduling in the absence of features like real-time priorities, etc.</div><div><br></div><div>If Thread.yield() is fixed, I also suggest that a thread calling LockSupport.unpark() does an implicit Thread.yield() - which should be very efficient if the number of runnable threads is less than the carrier thread count. Almost all lock-free structures use LockSupport park/unpark as their under pinnings, and this would allow things to work without preemption. This program forces this issue, but a lot of lock-free structures are based on the program making “some progress”. In this case, the designer could “know” that it takes at most N nanos of spinning before a consumer will take the object - but if there are enough other spinning vthreads “in that moment” you will have a hang. This will lead to hard to diagnose timing bugs.</div><div><br></div><div>For reference, using parkNanos(1) with native threads and 8 8 500000, it completes in 21 secs. Using virtual threads it completes in 7 secs!</div><div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">A proper Thread.yield() should provide even better performance.</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">Note as well, if you remove the parkNanos(1) and use native threads, the program completes successfully - albeit the cpus spin, spin, spin - so be careful. It takes 70 secs to run the above test.</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">*** all of the above said, in the original testing and why I opened this issue, the carrier threads did not look allocated - and still the unparked vthread never ran. I will continue to test using the original setup.</div><div style="color:rgb(0,0,0)"><br></div></div><div><br></div><div><br></div><div><div><blockquote type="cite"><div>On Dec 27, 2022, at 4:27 PM, robert engels <<a href="mailto:rengels@ix.netcom.com" target="_blank" rel="noreferrer">rengels@ix.netcom.com</a>> wrote:</div><br><div><div style="word-wrap:break-word;line-break:after-white-space">Hi devs,<div><br></div><div>First, <br><div><br></div><span>Thanks for this amazing work!!! It literally solves the only remaining problem Java had.</span></div><div><span><br></span></div><div><span>Sorry for the long email.</span></div><div><font><span><br></span></font><div>I have been very excited to test-drive Project Loom in JDK19. I have extensive experience in highly concurrent systems/HFT/HPC, so I usually :) know what I am doing.</div><div><br></div><div>For the easiest test, I took a highly threaded (connection based) server based system (Java port of Go’s <a href="http://nats.io/" target="_blank" rel="noreferrer">nats.io</a> message broker), and converted the threads to virtual threads. The project (jnatsd) is available <a href="https://github.com/robaho/jnatsd" target="_blank" rel="noreferrer">here</a>. The ‘master’ branch runs very well with excellent performance, but I thought switching to virtual threads might be able to improve things over using async IO, channels, etc. (I have a branch for this that works as well, but it is much more complex, and didn’t provide a huge performance benefit)/</div><div><br></div><div>There are two branches ’simple_virtual_threads’ and ‘virtual_threads’.</div><div><br></div><div>In the former, it is literally a 2 line change to enable the virtual threads but it doesn’t work. I narrowed it down the issue that LockSupport.unpark(thread) does not work consistently. At some point, the virtual thread is never scheduled again. I enabled the debug options and I see that the the virtual thread is in:</div><div><br></div><div><pre>yield0:365, Continuation (jdk.internal.vm)
yield:357, Continuation (jdk.internal.vm)
yieldContinuation:370, VirtualThread (java.lang)
park:499, VirtualThread (java.lang)
parkVirtualThread:2606, System$2 (java.lang)
park:54, VirtualThreads (jdk.internal.misc)
park:369, LockSupport (java.util.concurrent.locks)
run:88, Connection$ConnectionWriter (com.robaho.jnatsd)
run:287, VirtualThread (java.lang)
lambda$new$0:174, VirtualThread$VThreadContinuation (java.lang)
run:-1, VirtualThread$VThreadContinuation$$Lambda$50/0x0000000801065670 (java.lang)
enter0:327, Continuation (jdk.internal.vm)
enter:320, Continuation (jdk.internal.vm)
</pre><div>The instance state is:</div></div><div><br></div><div><div>this = {VirtualThread$VThreadContinuation@1775} </div><div> target = {VirtualThread$VThreadContinuation$lambda@1777} </div><div> arg$1 = {VirtualThread@1699} </div><div> scheduler = {ForkJoinPool@1781} </div><div> cont = {VirtualThread$VThreadContinuation@1775} </div><div> runContinuation = {VirtualThread$lambda@1782} </div><div> state = 2</div><div> parkPermit = true</div><div> carrierThread = null</div><div> termination = null</div><div> eetop = 0</div><div> tid = 76</div><div> name = ""</div><div> interrupted = false</div><div> contextClassLoader = {ClassLoaders$AppClassLoader@1784} </div><div> inheritedAccessControlContext = {AccessControlContext@1785} </div><div> holder = null</div><div> threadLocals = null</div><div> inheritableThreadLocals = null</div><div> extentLocalBindings = null</div><div> interruptLock = {Object@1786} </div><div> parkBlocker = null</div><div> nioBlocker = null</div><div> Thread.cont = null</div><div> uncaughtExceptionHandler = null</div><div> threadLocalRandomSeed = 0</div><div> threadLocalRandomProbe = 0</div><div> threadLocalRandomSecondarySeed = 0</div><div> container = {ThreadContainers$RootContainer$CountingRootContainer@1787} </div><div> headStackableScopes = null</div><div> arg$2 = {Connection$ConnectionWriter@1780} </div><div> scope = {ContinuationScope@1776} </div><div> parent = null</div><div> child = null</div><div> tail = {StackChunk@1778} </div><div> done = false</div><div> mounted = false</div><div> yieldInfo = null</div><div> preempted = false</div><div> extentLocalCache = null</div><div>scope = {ContinuationScope@1776} </div><div>child = null</div></div><div><br></div><div>As you see in the above, the parkPermit is true, but it never runs again.</div><div><br></div><div>In the latter branch, ‘virtual_threads’, I changed the lock-free RingBuffer class to use simple synchronized primitives - under the assumption that with virtual threads lock/wait/notify should be highly efficient. It worked, but it was nearly 2x slower than the original thread based lock-free implementation. So, I added a ’spin loop’ in the RingBuffer methods. This code is completely optional and can be no-op’d, and I was able to increase performance to above that of the Thread based version.</div><div><br></div><div>I dug a little deeper, and decided that using Thread.yield() should be even more efficient than LockSupport.parkNanos(1) - problem is that changing that simple line brings back the hangs. I think there is very little semantic difference between LockSupport.parkNanos(1) and Thread.yield() but the latter should avoid any timer scheduling. The RingBuffer code there is fairly trivial.</div><div><br></div><div>So, before I dig deeper, is this a known issue that Thread.yield() does not work as expected? Is it is known issue that LockSupport.unpark() fails to reschedule threads?</div><div><br></div><div>Is it possible because the VirtualThreads do not implement the Java memory model properly?</div><div><br></div><div>Any ideas how to further diagnose?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></blockquote></div><br></div></div></blockquote></div>