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

[David Holmes]

On Wed, 23 Nov 2022 00:25:00 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.
>
> 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).

This also made me wonder ... are we guaranteed the current thread is a JavaThread? If so the signature and use of `ObjectSynchronizer::inflate(Thread* current` could be changed. If not, isn't that a requirements for oop storage changes?

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

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