RFR: 8291555: Implement alternative fast-locking scheme [v52]

[Roman Kennke]

On Tue, 4 Apr 2023 12:57:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thanks @tstuefe . I see at that level if the object doesn't match the top of the lock-stack then we take the slow path. But then I'm lost - AFAICS the slow path is `InterpreterRuntime::monitorexit` and that doesn't have any fast-locking code in it at all ???
>
> I'm not sure what you mean. `InterpreterRuntime::monitorexit` will enter `ObjectSynchronizer::exit` which handles the fast-locking case under `if (LockingMode == 2)...`. Or am I misunderstanding you?
> 
> (I really wish for named constants instead of `1` and `2` constants though...)

> Is this code used for monitorexit or only returning from synchronized methods? If used for monitorexit there is no requirement that the monitor being unlocked was the last monitor locked. Balanced locking only requires the locks and unlocks are matched, not that they are perfectly nested ie. this is valid in bytecode:
> 
> ```
> monitorenter A
> monitorenter B
> monitorexit A
> monitorExit B
> ```

As Thomas mentioned, we check this in the interpreter paths, which are the only paths where this can happen. C1 and C2 would reject bytecode with unstructured locking. That's why we can assert for structured locking in MacroAssembler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157649461