RFR: 8256302: releasing oopStorage when deflating allows for faster deleting

[Daniel D. Daugherty]

On Fri, 2 Dec 2022 02:11:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I still think we should have been able to keep the release in the destructor guarded by some check:
>>> 
>>> ```
>>> if (! already_released) {
>>>   assert(!safepoint_safe, "must be");
>>>   _object.release(_oop_storage);
>>> }
>>> ```
>>> 
>>> but perhaps there is no way to ask if "already_released"?
>>> 
>>> Thanks for the additional comments on the why of all this. The constraints on when you can access oopStorage were not clear before.
>> 
>> You can ask by doing _object().is_null(), if true there is no backing storage in oopStorage.
>> Since the case above should never ever happen (cross-fingers) I would:
>> 
>> `guarantee(_object().is_null(), "Destructor should never be called if weak handle is not released");`
>
>> You can ask by doing `_object().is_null()`
> 
> Are you allowed to do that when safepoint-safe?

@dholmes-ora, @robehn, @kimbarrett and @coleenp - I have fixed the "easy" comments
with the latest commit.

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.

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

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