Synchronized methods and virtual threads

[Robert Engels]

Is there an issue that removes it, I only see https://bugs.openjdk.org/browse/JDK-8235256 <https://bugs.openjdk.org/browse/JDK-8235256> which has it still enabled.

Regardless, unless this was changed as well, the object monitors can shared and elided - something that a Lock instance cannot - making Object monitors far more memory efficient and performant. There may only be a few instances where large volume object locking is necessary, and you could probably redesign to use arenas, but the built-in locking primitives were foundational in Java’s genesis imo.

As to Nir Shavit, not sure I agree - developers have successfully built large-scale locking systems for quite a long time. You can try and go the CSP route of Go - but that often falls down in performance, and/or uses locks anyway.

> On Jun 3, 2024, at 9:34 AM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> 
> On 6/3/24 13:31, robert engels wrote:
> > Reference for synchronized being a code smell?
> 
> I'm not sure about any reference, but locking on arbitrary
> objects makes it hard to reason about a program. At least Locks
> are explicit locks, as advertised in their type.
> 
> > Synchronized methods can be much more efficient than locks as
> > the runtime can optimize them away,
> 
> "Much more" is a bit of a stretch here, but admittedly they do
> have better throughput in the mostly-uncontended case.
> 
> But re locks, I'm going to quote Nir Shavit:
> 
> "The main tools for handling concurrency in today's programming
> languages are locks, software constructs that allow sequences of
> loads and stores to access data in a mutually exclusive manner.
> Indeed, lock-based programs have been known to deliver amazing
> performance on multicore architectures. However, it is becoming
> clear that, while using locks will allow us to continue to reduce
> the time it takes programs to run, they will cause the time it
> takes us to write and maintain our programs to shoot back up.
> 
> "The heart of the problem is, perhaps, that no one really knows
> how to organize and maintain large systems that rely on locking.
> Locks are not modular and do not compose, and the association
> between locks and data is established mostly by convention.
> Ultimately, the association exists only in the mind of the
> programmer, and may be documented only in comments."
> 
> > bias locking, etc.
> 
> It can't use biased locking any more.
> 
> -- 
> 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/20240603/4aa44a02/attachment-0001.htm>