<div dir="ltr"><div dir="ltr">David,</div><div dir="ltr"><br></div><div dir="ltr">On Sun, Jan 18, 2026 at 11:04 PM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You would lose potentially important information when reporting monitors <br>
owned by a thread.</blockquote><div><br></div><div>I get that the class name may be useful for diagnostic purposes.</div><div><br></div><div>However, the new Object() idiom has several thousand occurrences across the JDK, while new Lock() revealed only these two (plus a few in tests).</div><div><br></div><div>These Lock classes seem like an easy win in the effort to trim the list of JDK class loading during startup/shutdown.</div><div><br></div><div>Do you feel that the diagnostic value added by using named classes for these two instances outweighs the benefit of trimming class loading during startup?</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also I think Valhalla is trying to dissuade/move-away-from using "new Object()".</blockquote></div><div><br></div><div>Hmm.. The alternative solution cannot be to introduce custom Lock classes everywhere, right?</div><div><br></div><div>Thanks,</div><div>Eirik.      </div></div></div>