<div dir="ltr"><div>Hi Alan,</div><div><br></div><div>Thanks for your reply. Responses inline below...</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> As promised, here is my second (shorter I hope!) email sharing <br>
> feedback on the recent Loom EA build (23-loom+4-102).<br>
<br>
Thank you for taking the time to write down your experiences, this is <br>
exactly the type of feedback that helps.<br></blockquote><div><br></div><div>It's a pleasure.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> :<br>
><br>
> ### Experiment #1: read stress test<br>
<br>
For #1 and #2, would it be correct to say that there is a lot of monitor <br>
contention? Your first mail talked about contention in the "multi-index <br>
write stress test" but I can't tell if this corresponds to #2 or #3 in <br>
thesecond mail.<br>
<br></blockquote><div><br></div><div>Sorry if it wasn't clear.</div><div><br></div><div>Experiment #1 is a read saturation test. There's very little monitor contention and the test is pretty much CPU bound.</div><div><br></div><div>Experiment #2 corresponds to the multi-index write stress test in my first message. This experiment uses transactions where each txn updates around 60 DB records, some of which are quite hot. The DB txn log critical section is entered for every record update (i.e. 60 times per txn in this test).</div><div><br></div><div>Experiment #3 is just an extreme version of experiment #2, which updates around 400 DB records per transaction, and therefore enters the txn log critical section ~400 times per txn.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is currently a performance/latency issue with the unblocking of <br>
virtual threads that were blocked on monitors (or Object.wait). That is <br>
being looked into and may contribute to some of what you are seeing.<br>
<br></blockquote><div><br></div><div>Ok, that's great to hear. I'd be interested in testing any more EA builds that attempt to address this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>...<br>
<br>
<br>
><br>
> :<br>
><br>
> The outliers with virtual threads are much much higher. Could this be <br>
> due to potential starvation when rescheduling virtual threads in the <br>
> fork join pool?<br>
><br>
It's hard to say. The current EA builds doesn't have the final <br>
ForkJoinPool change that went into JDK 23, we'll refresh the EA build <br>
soon. Another thing is that virtual threads that were blocked on a <br>
monitor are pushed to an unowned submission queue so they may not <br>
continue immediately if it a lot of other virtual thread <br>
parking/unparking going on - this might change with the monitor <br>
unblocking perf issue I mentioned. Another possibility is that <br>
unfairness that can happen when many threads are trying to enter. In <br>
your EA builds then the output from `jcmd <pid> <br>
Thread.vthread_scheduler` might help as it shows a count of the number <br>
of tasks (=threads) in the submission queues.<br><br></blockquote><div><br></div><div>I reran the test and executed the above command once per second for 10 seconds:</div><div><br></div><div>$ for i in 1 2 3 4 5 6 7 8 9 10; do jcmd DirectoryServer Thread.vthread_scheduler; sleep 1; done<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 13, running = 0, steals = 17676052, tasks = 0, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 16, running = 0, steals = 17784106, tasks = 1, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 20, running = 1, steals = 17887000, tasks = 1, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 15, running = 1, steals = 17984238, tasks = 1, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 9, running = 0, steals = 18082247, tasks = 0, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 9, running = 0, steals = 18201916, tasks = 0, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 20, running = 0, steals = 18302449, tasks = 2, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 1, running = 0, steals = 18416910, tasks = 0, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 13, running = 0, steals = 18516576, tasks = 0, submissions = 0]<br>110886:<br>java.util.concurrent.ForkJoinPool@3a7204cd[Running, parallelism = 20, size = 20, active = 14, running = 0, steals = 18602916, tasks = 0, submissions = 0]<br></div><div><br></div><div>I won't pretend to understand what this means :-)</div><div><br></div><div>Cheers,</div><div>Matt</div><div><br></div></div></div>