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

[Daniel D. Daugherty]

On Tue, 6 Jun 2023 19:53:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge tag 'jdk-21+25' into JDK-8256302
>>    
>>    Added tag jdk-21+25 for changeset a46b5acc
>>  - Allow ObjectMonitor::_object to be reset to nullptr when it is released which allows the code to be cleaner.
>>  - 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
>
> Marked as reviewed by coleenp (Reviewer).

@coleenp - Thanks for the re-review. I believe I've answered all the queries that you
had in this round of review.

> src/hotspot/share/runtime/objectMonitor.cpp line 282:
> 
>> 280:     // Release object's oop storage if it hasn't already been done.
>> 281:     release_object();
>> 282:   }
> 
> In what case, would the object's oop storage not already been released?  Is the destructor called here because of GC, where the object has been collected?

There are a couple of places where thread-A allocates an ObjectMonitor for inflation,
but thread-A loses the race to install an ObjectMonitor to thread-B so the ObjectMonitor
allocated by thread-A has to be deleted/freed.

In an earlier version of the patch I had `release_object()` calls in both of those locations
and a couple of the reviewers thought that was "clunky".

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

PR Comment: https://git.openjdk.org/jdk/pull/11296#issuecomment-1579378996
PR Review Comment: https://git.openjdk.org/jdk/pull/11296#discussion_r1220260176