RFR: 8320304: Refactor and simplify monitor deflation functions [v3]

[Daniel D. Daugherty]

On Tue, 21 Nov 2023 00:26:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a patch that removes the "safepointer" class:
>> https://github.com/openjdk/jdk/commit/2025d7a8e8d48d2d9af548d95b4a88a57058427c
>> 
>> And this is what the entire patch would look like:
>> https://github.com/openjdk/jdk/compare/master...stefank:jdk:8320304_cleanup_of_monitor_deflation_no_safepointer
>> 
>> Personally, I think this makes the code messier. Code that previously didn't have to care about logging now has to do so. It is also more obscure what function calls will perform the safepoint checking.
>
> I appreciate you took the time to trial this - that was not necessary unless others have similar comments.  Personally I find the patch without safepointer less disruptive from the safepointing pov.

> This is a patch that removes the "safepointer" class:
> https://github.com/openjdk/jdk/commit/2025d7a8e8d48d2d9af548d95b4a88a57058427c

This patch looks messier than it should because of a mis-indent in `ObjectSynchronizer::block_for_safepoint`
from L1659 -> 1671.

I could go either way with having the safepointing and associated logging hiding
inside ObjectMonitorDeflationSafepointer or not. When I read David's comment, I
thought he was not happy with both abstract objects (ObjectMonitorDeflationSafepointer
and ObjectMonitorDeflationLogging). Now that I reread his comments, I'm no longer
sure that the style objection is to both.

The way that I reviewed this was to make sure that all calls to `ObjectSynchronizer::chk_for_block_req`
had an appropriate replacement call to the new helper object APIs...

Rereading it all again, I'm leaning toward having both helper objects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16706#discussion_r1400941939