Robbin Ehn

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 ) at /home/rehn/source/jdk/ongit/dev-jdk/open/src/hotspot/share/runtime/thread.cpp:549 #8 0x00007f7cef22c062 in...

> > 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...

> Thanks for giving this PR a spin. I pushed a fix for the aarch64 build problem (seems weird that GHA did not catch it). NP, thanks. I notice some...

> > > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build problem (seems weird that GHA did not catch it). > > >...

> @robehn or @dholmes-ora I believe one of you mentioned somewhere (can't find the comment, though) that we might need to support the bytecode sequence monitorenter A; monitorenter B; monitorexit...

> Strictly speaking, I believe the conditions check for the (weaker) balanced property, but not for the (stronger) structured property. I know but the text says: - "every exit on...

Regarding benchmarks, is it possible to get some indication what fast-locking+lillput result will be? FinagleHttp seems to suffer a bit, will Lillput give some/all of that back, or more?

On aarch64 (linux and mac) I see these variations of crashes in random tests: (asserts in debug, crash in release it looks like) ``` # Internal Error .... src/hotspot/share/c1/c1_Runtime1.cpp:768), pid=2884803,...

> It used to be very stable before that. I have backed out that change, can you try again? Seems fine now, thanks. Update: I had some minor unrelated issues,...

First the "SharedRuntime::complete_monitor_locking_C" crash do not reproduce. Secondly, a question/suggestion: Many recursive cases do not interleave locks, meaning the recursive enter will happen with the lock/oop top of lock stack...