RFR: 8256302: releasing oopStorage when deflating allows for faster deleting
Robbin Ehn
rehn at openjdk.org
Wed Nov 30 08:24:19 UTC 2022
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.
To use oopStorage a JavaThread must be safepoint unsafe.
C-heap memory can be freed at anytime.
A monitor consist of two resources, an oopStorage allocation and C-heap allocation.
Doing them together means JavaThread must be safepoint unsafe.
Doing several thousands at the time can prolong safepoints.
Safepoint checking in this loop makes the deletion prolonged.
Once the monitor is deflated it is still visible and cannot be directly deleted.
But the JavaThread deflated it can release oopStorage. (no-one should be reading the oop from oopStorage)
So later when we want to C-heap free it, we can do from blocked state over thousands of monitors with checking for safepoints.
Did that make it clearer?
-------------
PR: https://git.openjdk.org/jdk/pull/11296
More information about the hotspot-runtime-dev
mailing list