On Mon, 8 Aug 2022 15:44:50 GMT, Robbin Ehn <r...@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@entry=0x7f7ce801dd90, adr=adr@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@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
