<div dir="ltr"><i><span style="color:rgb(80,0,80)">> 2. Is there any known audit-tool/compiler tool available that does some level of auto-conversion?</span><br style="color:rgb(80,0,80)"></i><div><br></div><div>I don't know of any auto-conversion tool.</div><div><br></div><div>Just to add in case it is useful that I think you are likely to use ReentrantLock with a <i>try finally</i>. Another option which was used with Postgres JDBC Driver was to have a ResourceLock extends ReentrantLock implements AutoCloseable and use <i>try-with-resources</i>.</div><div><br></div><div>Refer: <a href="https://github.com/pgjdbc/pgjdbc/pull/2635/files#diff-091eabe2ff632685f88c6dac943f9bc1a464bd2e79ff9907a43441e6e8fb90a3">https://github.com/pgjdbc/pgjdbc/pull/2635/files#diff-091eabe2ff632685f88c6dac943f9bc1a464bd2e79ff9907a43441e6e8fb90a3</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 31 Aug 2023 at 01:02, Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
----- Original Message -----<br>
> From: "Ron Pressler" <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>><br>
> To: "Shailesh Vinayaka" <<a href="mailto:shailesh.vinayaka@oracle.com" target="_blank">shailesh.vinayaka@oracle.com</a>><br>
> Cc: "loom-dev" <<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a>>, "Michel Trudeau" <<a href="mailto:michel.trudeau@oracle.com" target="_blank">michel.trudeau@oracle.com</a>><br>
> Sent: Wednesday, August 30, 2023 2:35:40 PM<br>
> Subject: Re: Auto-conversion of synchronized for loom.<br>
<br>
>> On 29 Aug 2023, at 22:32, Shailesh Vinayaka <<a href="mailto:shailesh.vinayaka@oracle.com" target="_blank">shailesh.vinayaka@oracle.com</a>><br>
>> wrote:<br>
>> <br>
>> Loom folks,<br>
>> <br>
>> We have been tasked to prepare our framework for loom and it seems the first<br>
>> order of business is to move all synchronized blocks to use reentrant locks.<br>
> <br>
> Hi.<br>
> No, you do not need to convert all synchronized blocks/methods to j.u.c locks,<br>
> only those that guard operations that are long-running and very frequent, i.e.<br>
> those that guard very frequent I/O (so not in-memory operations, unless you use<br>
> Object.wait, and not infrequent I/O such as that performed on initialisation).<br>
> <br>
>> For us it’d be a relatively huge project and before we embark, it’ll help to get<br>
>> clarification on these questions:<br>
>> <br>
>> 1. Is there a blocking reason why jdk did not convert the synchronized blocks to<br>
>> closures implementing reentrant lock/unlock via some compiler or opt-in flag?<br>
> <br>
> Yes. Doing so in an acceptably efficient manner is difficult. Any Java object<br>
> could potentially be synchronized on so a simple conversion of the kind you<br>
> describe would require adding one field to every Java object that would refer<br>
> to the lock object if one is used; that is an unacceptable increase in<br>
> footprint.<br>
<br>
Or you can use Google Common Cache [1] or Cafeine [2] to store the ReentrantLocks inside a concurrent cache with weak keys.<br>
<br>
> <br>
> — Ron<br>
<br>
Rémi<br>
<br>
[1] <a href="https://guava.dev/releases/23.0/api/docs/com/google/common/cache/CacheBuilder.html" rel="noreferrer" target="_blank">https://guava.dev/releases/23.0/api/docs/com/google/common/cache/CacheBuilder.html</a><br>
[2] <a href="https://github.com/ben-manes/caffeine" rel="noreferrer" target="_blank">https://github.com/ben-manes/caffeine</a><br>
<br>
</blockquote></div>