RFR: 8291418: adjust monitor deflation logging and deflate_idle_monitors use

[Patricio Chilano Mateo]

On Tue, 29 Nov 2022 21:51:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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`.

But isn't the delete_list local to the MonitorDeflation thread? How can the VMThread access those unlinked but not deleted monitors?

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

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