Auto-conversion of synchronized for loom.

[Ron Pressler]

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

On the other hand, we are working on more sophisticated ways that would make synchronized blocks/methods virtual-thread-friendly, i.e. block only the virtual thread and not any OS thread. I don’t know how long that will take, but it’s a high priority item that we’re putting a lot of effort into.

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

I don’t know.

> 
> Thank you for your help and please reply directly as I am not a member of the mailing list.
> Shailesh.
> 
> 

— Ron