Auto-conversion of synchronized for loom.

[Rob Bygrave]

*> 2. Is there any known audit-tool/compiler tool available that does some
level of auto-conversion?*

I don't know of any auto-conversion tool.

Just to add in case it is useful that I think you are likely to use
ReentrantLock with a *try finally*. Another option which was used with
Postgres JDBC Driver was to have a ResourceLock extends ReentrantLock
implements AutoCloseable and use *try-with-resources*.

Refer:
https://github.com/pgjdbc/pgjdbc/pull/2635/files#diff-091eabe2ff632685f88c6dac943f9bc1a464bd2e79ff9907a43441e6e8fb90a3

On Thu, 31 Aug 2023 at 01:02, Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ----- Original Message -----
> > From: "Ron Pressler" <ron.pressler at oracle.com>
> > To: "Shailesh Vinayaka" <shailesh.vinayaka at oracle.com>
> > Cc: "loom-dev" <loom-dev at openjdk.org>, "Michel Trudeau" <
> michel.trudeau at oracle.com>
> > Sent: Wednesday, August 30, 2023 2:35:40 PM
> > Subject: Re: Auto-conversion of synchronized for loom.
>
> >> On 29 Aug 2023, at 22:32, Shailesh Vinayaka <
> shailesh.vinayaka at oracle.com>
> >> wrote:
> >>
> >> Loom folks,
> >>
> >> We have been tasked to prepare our framework for loom and it seems the
> first
> >> order of business is to move all synchronized blocks to use reentrant
> locks.
> >
> > Hi.
> > No, you do not need to convert all synchronized blocks/methods to j.u.c
> locks,
> > only those that guard operations that are long-running and very
> frequent, i.e.
> > those that guard very frequent I/O (so not in-memory operations, unless
> you use
> > Object.wait, and not infrequent I/O such as that performed on
> initialisation).
> >
> >> For us it’d be a relatively huge project and before we embark, it’ll
> help to get
> >> clarification on these questions:
> >>
> >> 1. Is there a blocking reason why jdk did not convert the synchronized
> blocks to
> >> closures implementing reentrant lock/unlock via some compiler or opt-in
> flag?
> >
> > Yes. Doing so in an acceptably efficient manner is difficult. Any Java
> object
> > could potentially be synchronized on so a simple conversion of the kind
> you
> > describe would require adding one field to every Java object that would
> refer
> > to the lock object if one is used; that is an unacceptable increase in
> > footprint.
>
> Or you can use Google Common Cache [1] or Cafeine [2] to store the
> ReentrantLocks inside a concurrent cache with weak keys.
>
> >
> > — Ron
>
> Rémi
>
> [1]
> https://guava.dev/releases/23.0/api/docs/com/google/common/cache/CacheBuilder.html
> [2] https://github.com/ben-manes/caffeine
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230831/a68783ae/attachment.htm>