RFR: 8291555: Replace stack-locking with fast-locking

[Robbin Ehn]

On Fri, 9 Sep 2022 19:01:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> How have you handled the interpreter lock-stack-area in your implementation? Is it worth to get rid of it and consolidate with the per-thread lock-stack?

At the moment I had to store a "frame id" for each entry in the lock stack.
The frame id is previous fp, grabbed from "link()" when entering the locking code.

    private static final void monitorEnter(Object o) {
....
        long monitorFrameId = getCallerFrameId();
``` 
When popping we can thus check if there is still monitors/locks for the frame to be popped.
Remove activation reads the lock stack, with a bunch of assembly, e.g.:
`  access_load_at(T_INT, IN_HEAP, rax, Address(rax, java_lang_Thread::lock_stack_pos_offset()), noreg, noreg);
`
If we would keep this, loom freezing would need to relativize and derelativize these values.
(we only have interpreter)

But, according to JVMS 2.11.10. the VM only needs to automatically unlock synchronized method.
This code that unlocks all locks in the frame seems to have been added for JLS 17.1.
I have asked for clarification and we only need and should care about JVMS.

So if we could make popframe do more work (popframe needs to unlock all), there seems to be way forward allowing more flexibility.

Still working on trying to make what we have public, even if it's in roughly shape and it's very unclear if that is the correct approach at all.

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

PR: https://git.openjdk.org/jdk/pull/9680