[code-reflection] RFR: Model synchronized statements

[Maurizio Cimadamore]

On Tue, 20 Aug 2024 20:43:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Model synchronized statements.
> 
> A synchronized op has two bodies one for the expression yielding the monitor and one for the synchronized block that covers the monitor enter and exit.
> 
> The lowering of synchronized op produces a model containing monitor enter and exit operations and operations covered by exception regions, ensuring that a monitor exits under exceptional circumstances. 
> 
> The interpreter has been updated, but locking is currently on a best effort basis using `ReentrantLock` instances thus we cannot consistently apply synchronization on objects across interpretation, executing in a single thread, and bytecode executing in one or more other threads.  We would need to update the interpreter to use native methods that invoke the JNI `MonitorEnter` and `MonitorExit` methods, although it is not clear if those can be mixed in a nested manner with JVM execution of monitor enter and exit bytecode instructions.
> 
> A simple test for generated bytecode has been included that tests for the expected number of monitor enter and exit instructions, and single threaded execution for non-exceptional and exceptional cases.

src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java line 567:

> 565:                     .map(String::valueOf)
> 566:                     .collect(Collectors.joining());
> 567:         } else if (o instanceof CoreOp.MonitorOp.MonitorEnterOp) {

Crazy suggestion: given the recent push of making more of the monitor logic be expressed in Java (as part of Loom), I wonder if it would make sense to imagine a world where a `synchronized` is just lowered to plain Java code - no special core ops? The really fundamental operation that cannot be expressed here is the "gimme a lock for this object". But if we had that (and that is a single core op, or maybe just expressed as a special "field access") wouldn't we be able to achieve the same result?

e.g.


lock = lockFor(synchronizedValue)
lock.lock();
try {
    // stats
} finally {
    lock.unlock();
}

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/217#discussion_r1728622630