Re: Object-based monitors vs Lock based-monitors for JDK 17+

On 9/29/21 17:50, Pedro Felix via Concurrency-interest wrote:
> However, for simple scenarios where both are applicable, which should we
> use? Are there any performance or other advantages in using Object-based
> vs. Lock-based monitors?

One caveat: any answer is going to be specific to HotSpot. And my
answer is that of a HotSpot developer.

Having said that, HotSpot has hand-coded intrinsics for its built-in
monitors. For that reason, at times of low contention they're going
to be hard to beat, and we can even do hardware lock elision.
Also, HotSpot does some lock coarsening for built-in monitors. if
you have high contention, it's not so clear and one of the j.u.c. locks
might be a better idea. Lock-free structures might be a better idea still.

> Also, which are preferable when using Loom's virtual threads? I recall
> reading that there may be limitations around Object-based monitors and
> virtual threads, such as blocking the carrier thread.

Quite. If you expect to do anything that might block, don't use a
built-in monitor. If you expect a lot of threads to be contending
for some resource don't use a built-in monitor.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671