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

[Daniel D. Daugherty]

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.

src/hotspot/share/runtime/objectMonitor.cpp line 279:

> 277: 
> 278: ObjectMonitor::~ObjectMonitor() {
> 279:   _object.release(_oop_storage);

Just to be clear, we can't call release here because not all
`delete monitor` calls happen while the JavaThread is in VM.
Some happen while the JavaThread is blocked.

src/hotspot/share/runtime/objectMonitor.cpp line 598:

> 596: 
> 597:   // Release object's oop storage since the ObjectMonitor has been deflated:
> 598:   release_object();

Just to be clear, deflate_monitor() is called when a JavaThread is
in VM (or by the VM Thread) so it is safe to call release.

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

> 1358:     if (object->cas_set_mark(markWord::encode(m), mark) != mark) {
> 1359:       // Release object's oop storage since we don't need this ObjectMonitor:
> 1360:       m->release_object();

Just to be clear, inflate() is called when a JavaThread is
in VM (or by the VM Thread) so it is safe to call release.

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

> 1476:   size_t count = 0;
> 1477:   for (ObjectMonitor* monitor: delete_list) {
> 1478:     delete monitor;

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.

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

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