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

[David Holmes]

On Tue, 22 Nov 2022 17:52:45 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.

Seems okay in principal, but some queries on the details.

Thanks.

src/hotspot/share/runtime/synchronizer.cpp line 1266:

> 1264:       if (cmp != mark) {
> 1265:         // Release object's oop storage since we don't need this ObjectMonitor:
> 1266:         m->release_object();

This looks a bit clunky - the caller should not need to know about the ObjectMonitor internals with regards to Oop storage management. Can't we keep the release in the destructor but guard it (if necessary) with a check to see if it is already released? It would be nice if release could be called more than once and was a no-op if already released. (I can't make enough sense of the Access API to know whether this is feasible/possible).

src/hotspot/share/runtime/synchronizer.cpp line 1560:

> 1558:       }
> 1559:       // Make the calling JavaThread blocked (safepoint safe) while we
> 1560:       // free the ObjectMonitors:

Suggestion s/Make/Mark/

src/hotspot/share/runtime/synchronizer.cpp line 1572:

> 1570:     } else {
> 1571:       // A non-JavaThread can just free the ObjectMonitors:
> 1572:       deleted_count = delete_monitors(delete_list);

Which non-JavaThread can execute this code?

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

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