<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Is there an issue that removes it, I only see <a href="https://bugs.openjdk.org/browse/JDK-8235256" class="">https://bugs.openjdk.org/browse/JDK-8235256</a> which has it still enabled.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 3, 2024, at 9:34 AM, Andrew Haley <<a href="mailto:aph-open@littlepinkcloud.com" class="">aph-open@littlepinkcloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 6/3/24 13:31, robert engels wrote:<br class="">> Reference for synchronized being a code smell?<br class=""><br class="">I'm not sure about any reference, but locking on arbitrary<br class="">objects makes it hard to reason about a program. At least Locks<br class="">are explicit locks, as advertised in their type.<br class=""><br class="">> Synchronized methods can be much more efficient than locks as<br class="">> the runtime can optimize them away,<br class=""><br class="">"Much more" is a bit of a stretch here, but admittedly they do<br class="">have better throughput in the mostly-uncontended case.<br class=""><br class="">But re locks, I'm going to quote Nir Shavit:<br class=""><br class="">"The main tools for handling concurrency in today's programming<br class="">languages are locks, software constructs that allow sequences of<br class="">loads and stores to access data in a mutually exclusive manner.<br class="">Indeed, lock-based programs have been known to deliver amazing<br class="">performance on multicore architectures. However, it is becoming<br class="">clear that, while using locks will allow us to continue to reduce<br class="">the time it takes programs to run, they will cause the time it<br class="">takes us to write and maintain our programs to shoot back up.<br class=""><br class="">"The heart of the problem is, perhaps, that no one really knows<br class="">how to organize and maintain large systems that rely on locking.<br class="">Locks are not modular and do not compose, and the association<br class="">between locks and data is established mostly by convention.<br class="">Ultimately, the association exists only in the mind of the<br class="">programmer, and may be documented only in comments."<br class=""><br class="">> bias locking, etc.<br class=""><br class="">It can't use biased locking any more.<br class=""><br class="">-- <br class="">Andrew Haley (he/him)<br class="">Java Platform Lead Engineer<br class="">Red Hat UK Ltd. <<a href="https://www.redhat.com" class="">https://www.redhat.com</a>><br class=""><a href="https://keybase.io/andrewhaley" class="">https://keybase.io/andrewhaley</a><br class="">EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>