Experience using virtual threads in EA 23-loom+4-102

[Matthew Swift]

Hi Alan,

Thanks for your reply. Responses inline below...

>
> > As promised, here is my second (shorter I hope!) email sharing
> > feedback on the recent Loom EA build (23-loom+4-102).
>
> Thank you for taking the time to write down your experiences, this is
> exactly the type of feedback that helps.
>

It's a pleasure.


>
> > :
> >
> > ### Experiment #1: read stress test
>
> For #1 and #2, would it be correct to say that there is a lot of monitor
> contention? Your first mail talked about contention in the "multi-index
> write stress test" but I can't tell if this corresponds to #2 or #3 in
> thesecond mail.
>
>
Sorry if it wasn't clear.

Experiment #1 is a read saturation test. There's very little monitor
contention and the test is pretty much CPU bound.

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).

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.


> This is currently a performance/latency issue with the unblocking of
> virtual threads that were blocked on monitors (or Object.wait). That is
> being looked into and may contribute to some of what you are seeing.
>
>
Ok, that's great to hear. I'd be interested in testing any more EA builds
that attempt to address this.


>
> ...
>
>
> >
> > :
> >
> > The outliers with virtual threads are much much higher. Could this be
> > due to potential starvation when rescheduling virtual threads in the
> > fork join pool?
> >
> It's hard to say. The current EA builds doesn't have the final
> ForkJoinPool change that went into JDK 23, we'll refresh the EA build
> soon. Another thing is that virtual threads that were blocked on a
> monitor are pushed to an unowned submission queue so they may not
> continue immediately if it a lot of other virtual thread
> parking/unparking going on - this might change with the monitor
> unblocking perf issue I mentioned. Another possibility is that
> unfairness that can happen when many threads are trying to enter. In
> your EA builds then the output from `jcmd <pid>
> Thread.vthread_scheduler` might help as it shows a count of the number
> of tasks (=threads) in the submission queues.
>
>
I reran the test and executed the above command once per second for 10
seconds:

$ for i in 1 2 3 4 5 6 7 8 9 10; do jcmd DirectoryServer
Thread.vthread_scheduler; sleep 1; done
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 13, running = 0, steals = 17676052, tasks = 0, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 16, running = 0, steals = 17784106, tasks = 1, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 20, running = 1, steals = 17887000, tasks = 1, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 15, running = 1, steals = 17984238, tasks = 1, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 9, running = 0, steals = 18082247, tasks = 0, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 9, running = 0, steals = 18201916, tasks = 0, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 20, running = 0, steals = 18302449, tasks = 2, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 1, running = 0, steals = 18416910, tasks = 0, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 13, running = 0, steals = 18516576, tasks = 0, submissions =
0]
110886:
java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size
= 20, active = 14, running = 0, steals = 18602916, tasks = 0, submissions =
0]

I won't pretend to understand what this means :-)

Cheers,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240624/f2eb6fc1/attachment.htm>