Replacing monitors with locks

[Danny Thomas]

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.

On Thu, Jul 11, 2024 at 6:04 PM Volkan Yazıcı <volkan at yazi.ci> wrote:

> Hello,
>
> I interpreted the Quality Outreach Heads-up for the upcoming Java 23
> <https://inside.java/2024/06/22/quality-heads-up/>, 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. Yet Attila Kelemen
> pointed in a Log4j ticket
> <https://github.com/apache/logging-log4j2/issues/1532#issuecomment-2221176844>
> to this particular `loom-dev` post by Ron Pressler
> <https://mail.openjdk.org/pipermail/loom-dev/2024-July/006885.html>:
>
> *"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."*
>
> 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?
>
> Kind regards.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240711/7d3f6f34/attachment.htm>