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

[Daniel D. Daugherty]

On Wed, 30 Nov 2022 05:12:15 GMT, David Holmes <dholmes 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.
>
> I'm really not following the conversation around "we can't do release while _thread_blocked and so we can't release in the destructor" - when would we call the destructor whilst _thread_blocked? And why?

@dholmes-ora
> when would we call the destructor whilst _thread_blocked? And why?

I added some comments in this PR yesterday to point out the critical
locations that have been tweaked by this PR:

This is where `delete_monitors()` calls `delete` in the new code:

https://github.com/openjdk/jdk/pull/11296/files#r1035290679


And right after this comment block that you commented on is where
we create a `ThreadBlockInVM` helper and call `delete_monitors()`:

https://github.com/openjdk/jdk/pull/11296/files#r1029941463

As for the "and why?" part, this is the crux of the fix. @robehn noticed that
if we could release the Oop Storage when we deflated the ObjectMonitors,
then we could handle the free'ing of the rest of the ObjectMonitor while
the thread was in blocked state. That separation would allow the VM Thread
to go to a safepoint more quickly because the MonitorDeflation thread was
already "blocked".

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

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