Auto-conversion of synchronized for loom.

[Remi Forax]

----- 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