RFR: 8291418: adjust monitor deflation logging and deflate_idle_monitors use

[Daniel D. Daugherty]

On Wed, 23 Nov 2022 16:25:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Trivial fixes to monitor deflation logging and deflate_idle_monitors use.
>
> src/hotspot/share/runtime/synchronizer.cpp line 1551:
> 
>> 1549:   if (ls != NULL) {
>> 1550:     timer.stop();
>> 1551:     if (deflated_count != 0 || unlinked_count != 0 || deleted_count != 0 || log_is_enabled(Debug, monitorinflation)) {
> 
> Why check both unlinked_count and deleted_count? Shouldn't they be equal if we got here?

If memory serves, it's possible for the final safepoint to catch
the MonitorDeflation thread while it's working in here at different
phases of the `deflate_idle_monitors()` work. When the VM Thread
comes in here for the "final audit" it can find different amounts of
work to do in the different phases because the MonitorDeflation
thread might have deflated N monitors, but it wasn't able to unlink
them all. When the VM Thread does its pass, it may deflate fewer
monitors (M), but may find N+M monitors need to be unlinked and
deleted.

Similarly, I think it's possible for the MonitorDeflation thread to
deflate N monitors and unlink N monitors, but then block for the
final safepoint. When the VMThread comes along, it may delete
fewer monitors(M) and unlink fewer monitors(M), but may find
N+M monitors need to be deleted. If the VM Thread's M value is
zero, then it will have `deflated_count == 0`, `unlinked_count == 0`
and `deleted_count != 0`.

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

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