RFR: 8256302: releasing oopStorage when deflating allows for faster deleting [v3]

[Daniel D. Daugherty]

On Mon, 22 May 2023 20:02:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Releasing ObjectMonitor oopStorage earlier when deflating allows ObjectMonitor
>> deletion by a JavaThread (usually the MonitorDeflationThread) to happen while a
>> ThreadBlockInVM helper is in place. This should improve time-to-safepoint.
>
> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge tag 'jdk-21+23' into JDK-8256302
>    
>    Added tag jdk-21+23 for changeset 6d4782bc
>  - address the easy dholmes and kimbarrett CR comments
>  - 8256302: releasing oopStorage when deflating allows for faster deleting

Coming back to this comment from way back on 2022.12.02:

> I tried out this change last night:
> 
> ```
> $ git diff
> diff --git a/src/hotspot/share/runtime/objectMonitor.cpp b/src/hotspot/share/runtime/objectMonitor.cpp
> index 2973e525cd4..e322b709b89 100644
> --- a/src/hotspot/share/runtime/objectMonitor.cpp
> +++ b/src/hotspot/share/runtime/objectMonitor.cpp
> @@ -276,6 +276,7 @@ ObjectMonitor::ObjectMonitor(oop object) :
>  { }
>  
>  ObjectMonitor::~ObjectMonitor() {
> +  guarantee(_object.is_null(), "Destructor must never be called if weak handle is not released.");
>  }
>  
>  oop ObjectMonitor::object() const {
> ```
> 
> and I got a crashing during the build process which reminds of when I tried to do the release conditionally in the destructor. I'll chase this down again and will record the results of the investigation in this PR when I'm done.
> 
> The bad news is the crash that I got last night caused `launchd` to get hung on my MBP13. I ended up having to power-cycle reboot the machine this AM when it didn't come back... The good news that I still have a way to reproduce the `launchd` getting stuck failure mode that we've been seeing in Mach5.


I've restored the one liner in the current version of the patch:

$ git diff
diff --git a/src/hotspot/share/runtime/objectMonitor.cpp b/src/hotspot/share/runtime/objectMonitor.cpp
index d1bd90b1bfd..7f4439243ad 100644
--- a/src/hotspot/share/runtime/objectMonitor.cpp
+++ b/src/hotspot/share/runtime/objectMonitor.cpp
@@ -276,6 +276,7 @@ ObjectMonitor::ObjectMonitor(oop object) :
 { }
 
 ObjectMonitor::~ObjectMonitor() {
+  if (UseNewCode) guarantee(_object.is_null(), "Destructor must never be called if weak handle is not released.");
 }
 
 oop ObjectMonitor::object() const {


and reran the usual: `java -XX:+UseNewCode Inflate2 30` with slowdebug bits:

#  Internal Error (/System/Volumes/Data/work/shared/bug_hunt/8256302_for_jdk20.git/open/src/hotspot/share/runtime/objectMonitor.cpp:279), pid=35313, tid=42243
#  guarantee(_object.is_null()) failed: Destructor must never be called if weak handle is not released.
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (slowdebug build 21-internal-LTS-2023-05-21-1503423.dcubed...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 21-internal-LTS-2023-05-21-1503423.dcubed..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)

<snip>

---------------  T H R E A D  ---------------

Current thread (0x00007fb4d500fa10):  JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=42243, stack(0x0000700005abb000,0x0000700005bbb000) (1024K)]

Stack: [0x0000700005abb000,0x0000700005bbb000],  sp=0x0000700005bba4a0,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x13836d6]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x906  (objectMonitor.cpp:279)
V  [libjvm.dylib+0x1383d89]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x89
V  [libjvm.dylib+0x6ec9cc]  report_vm_error(char const*, int, char const*, char const*, ...)+0x1ac
V  [libjvm.dylib+0xfefd44]  ObjectMonitor::~ObjectMonitor()+0x64
V  [libjvm.dylib+0xfefd75]  ObjectMonitor::~ObjectMonitor()+0x15
V  [libjvm.dylib+0x1279b84]  delete_monitors(GrowableArray<ObjectMonitor*>*)+0x84
V  [libjvm.dylib+0x12796d0]  ObjectSynchronizer::deflate_idle_monitors(ObjectMonitorsHashtable*)+0x510
V  [libjvm.dylib+0xfa0fdb]  MonitorDeflationThread::monitor_deflation_thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.dylib+0xaea5bb]  JavaThread::thread_main_inner()+0x14b
V  [libjvm.dylib+0xaea2fd]  JavaThread::run()+0x17d
V  [libjvm.dylib+0x12cba5e]  Thread::call_run()+0x15e
V  [libjvm.dylib+0x10298e7]  thread_native_entry(Thread*)+0x117
C  [libsystem_pthread.dylib+0x68fc]  _pthread_start+0xe0
C  [libsystem_pthread.dylib+0x2443]  thread_start+0xf


So it's nice that things are still the same as back on 2022.12.02... now I
can dig in and get to the bottom of this issue (that still doesn't make any
sense to me)...

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

PR Comment: https://git.openjdk.org/jdk/pull/11296#issuecomment-1561923481