Synchronized methods and virtual threads

[Alex Otenko]

I think it is not about performance, but language support of correctness.

So to speak, the language provides statements to build programs that are
obviously sequentially consistent. (With the caveat that deadlocks probably
are evidence of the execution that is not sequentially consistent)

On Tue, 4 Jun 2024, 09:06 Andrew Haley, <aph-open at littlepinkcloud.com>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240604/deed8015/attachment.htm>