Experience of adding JDK21 virtual thread support to a DB application

[Matthew Swift]

Thanks for the great tip Ron.

I had a look at how spinning is performed for Object monitors (
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/objectMonitor.cpp#L1790)
in order to get an idea of how much spinning should be performed before
blocking. Judging by the adaptive heuristics, it's obviously quite a
complex topic, especially in the general case. Despite that, I wondered if
a fixed number of spin iterations would suffice in my specific use-case
given that it is a single hot critical section with a well defined fixed
length. Sure enough a few experiments revealed that spinning for 200-500
iterations seemed to get the best results for new and old multi-core
hardware, so I now have performance back on a par with Object monitors.

I will be able to revert back to using Object monitors once the recent
monitor support has been officially released, because the Object monitor
spin heuristics are more likely to work well across a wider range of
hardware both now and in the future.

Cheers,
Matt


On Sat, 29 Jun 2024 at 15:54, Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 21 Jun 2024, at 16:57, Matthew Swift <matthew.swift at gmail.com> wrote:
> >
> > I know that ReentrantLock is supposed to be a little bit less efficient
> in highly contended situations, but I was surprised by an 8-10% impact. Is
> that expected?
>
>
> I wouldn’t say at all that it’s supposed to be slightly less efficient but
> rather, as Alan mentioned, the behaviour of ReentrantLock and native
> monitors is a little different — monitors spin for a bit before blocking.
> The reason this isn’t the default for ReentrantLock is that this may or may
> not be what you want, depending on circumstance. However, the ReentrantLock
> API supports adding spinning manually with a loop calling
> ReentrantLock.tryLock in the condition and Thread.onSpinWait in the body.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240706/727f666b/attachment.htm>