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

[Roman Kennke]

On Mon, 8 Aug 2022 15:44:50 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> I ran some test locally, 4 JDI fails and 3 JVM TI, all seems to fail in:
> 
> ```
> #7  0x00007f7cefc5c1ce in Thread::is_lock_owned (this=this at entry=0x7f7ce801dd90, adr=adr at entry=0x1 <error: Cannot access memory at address 0x1>) at /home/rehn/source/jdk/ongit/dev-jdk/open/src/hotspot/share/runtime/thread.cpp:549
> #8  0x00007f7cef22c062 in JavaThread::is_lock_owned (this=0x7f7ce801dd90, adr=0x1 <error: Cannot access memory at address 0x1>) at /home/rehn/source/jdk/ongit/dev-jdk/open/src/hotspot/share/runtime/javaThread.cpp:979
> #9  0x00007f7cefc79ab0 in Threads::owning_thread_from_monitor_owner (t_list=<optimized out>, owner=owner at entry=0x1 <error: Cannot access memory at address 0x1>)
>     at /home/rehn/source/jdk/ongit/dev-jdk/open/src/hotspot/share/runtime/threads.cpp:1382
> ```

Thanks, Robbin! That was a bug in JvmtiBase::get_owning_thread() where an anonymous owner must be converted to the oop address before passing down to Threads::owning_thread_from_monitor_owner(). I pushed a fix. Can you re-test? Testing com/sun/jdi passes for me, now.

> I didn't realize you still also is using the frame basic lock area. (in other projects this is removed and all cases are handled via the threads lock stack) So essentially we have two lock stacks when running in interpreter the frame area and the LockStack.
> 
> That explains why I have not heard anything about popframe and friends :)

Hmm yeah, I also realized this recently :-D
I will have to clean this up before going further. And I'll also will work to support the unstructured locking in the interpreter.

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

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