Synchronized methods and virtual threads

[Andrew Haley]

On 6/3/24 21:09, Cay Horstmann wrote:

 > And why make the lock be "this" so it leaks to the public? Per
 > Brinch Hansen wasn't amused: "It is astonishing to me that Java 's
 > insecure parallelism is taken seriously by the programming
 > community, a quarter of a century after the invention of monitors
 > and Concurrent Pascal. It has no merit."

Oh, I'd never seen that comment! Thanks for the reference.

 > Nothing wrong with an expert using synchronized because it performs
 > better. But that begs the question. Why does it perform better?
 > Objects typed as locks are surely more suitable as locks than any
 > old object. Their performance should be on par with intrinsic locks.

It's an interesting question. I think the real answer to that is
because java.util.concurrent locks are a pure library feature. The
virtual machine doesn't know anything about their properties so can't,
for example, do lock coarsening. But in principle, sure, the same
optimizations could be done. However, there would always have to be
a link from an object to its lock, which is a small overhead.

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