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

[David Holmes]

On Sun, 4 Jun 2023 14:18:41 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 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

I'm finding it a bit hard to follow the logic here and I think some older PR comments may be causing me some confusion.

IIUC the key enhancement here is that when we deflate we will also release the oop_storage, and in doing so we mark the `_object` as null so that the destructor skips also trying to do a release. Otherwise the destructor of OM will take care of the release when we `deflate_idle_monitors`. In the latter case we make the current JavaThread `_thread_blocked` so it doesn't delay safepoints. Is that all correct?

Thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/11296#pullrequestreview-1461491055