Loom And Synchronized

Jonas Nordin jonas.j.nordin at gmail.com
Wed Apr 6 14:41:37 UTC 2022


Hey fellow threaders. I've got an idea about how to possibly avoid some of
the rewriting due to the 'conflict' between how Loom is implemented, and
the 'synchronized' monitor mechanism.

The basic idea is simply to introduce a 'Synchronizable' interface type.
This type might look something like this:

public interface Synchronizable {
   AutoCloseable enterSynchronization();
}

and, then modify compilers to check for this type in 'synchronized'
constructs, and simply emit code similar to a try-with-resources block.
Shouldn't be a complicated transformation. So then, types used in
'synchronized', can be slightly modified to not use monitors, but
ReentrantLock or whatever is recommended instead.

The standard library might also supply a base class, maybe
'ReentrantSynchronizable'.

Now that I think about this, I realise this won't be exactly
backwards-compatible, but, for older compilers, the old synchronized kicks
in (not recognizing the 'Synchronizable') and should work the same (unless
the 'enterSynchronization()' method is buggy), and that will only be used
with older Java code, for which Loom is not used anyway.

Well that's the idea. Maybe it's been suggested before. What do you think?


More information about the loom-dev mailing list