On Fri, 9 Sep 2022 19:01:14 GMT, Roman Kennke <rken...@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
