<div dir="ltr">I was going to ask the same question. We are planning a blog post on our experience with virtual threads, and wanted to clarify so we can add recommendations and pass them on to upstream library producers when we're reporting bugs/performance issues.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 11, 2024 at 6:04 PM Volkan Yazıcı <<a href="mailto:volkan@yazi.ci">volkan@yazi.ci</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I interpreted <a href="https://inside.java/2024/06/22/quality-heads-up/" target="_blank">the Quality Outreach Heads-up for the upcoming Java 23</a>, sharing improvements on the way Loom handles monitors, as Loom will eventually handle monitors (in particular, carrier thread pinning issues) decently and remove the need to replace all `synchronized` usages with locks. <a href="https://github.com/apache/logging-log4j2/issues/1532#issuecomment-2221176844" target="_blank">Yet Attila Kelemen pointed in a Log4j ticket</a> to <a href="https://mail.openjdk.org/pipermail/loom-dev/2024-July/006885.html" target="_blank">this particular `loom-dev` post by Ron Pressler</a>:</div><div><br></div><div><i>"Unfortunately, while monitors would no longer pin virtual threads, their performance would suffer significantly when using virtual threads, and in general we recommend using j.u.c locks in new code anyway, because that implementation is likely to see further improvement, while monitors probably won’t."</i></div><br><div>Am I right to conclude that even though the monitors will eventually no longer pin threads, replacing them with locks is still (and also will be so for the foreseeable future?) the recommended practice for performance and sustainability reasons?</div><div><br></div><div>Kind regards.</div><div><br></div></div>
</blockquote></div>