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

[David Holmes]

On Tue, 29 Nov 2022 21:15:09 GMT, Daniel D. Daugherty <dcubed 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
>
> src/hotspot/share/runtime/synchronizer.cpp line 1655:
> 
>> 1653:     case inflate_cause_hash_code:      return "Monitor Hash Code";
>> 1654:     case inflate_cause_jni_enter:      return "JNI Monitor Enter";
>> 1655:     case inflate_cause_jni_exit:       return "JNI Monitor Exit";
> 
> Just to be clear, this is the "delete monitor" call that is happening
> while the calling JavaThread is in blocked state. If we did the release
> of the oop in the ObjectMonitor in the ObjectMonitor's destructor, then
> we would be calling release from blocked and not from thread-in-vm.

This comment doesn't make sense to me. We are calling release whilst blocked IIUC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11296#discussion_r1217318188