RFR(L) 8153224 Monitor deflation prolong safepoints (CR11/v2.11/14-for-jdk15)

[Erik Österlund]

Replying to myself here.

On 2020-05-15 13:07, Erik Österlund wrote:
> Oh and we probably need a normal loadload() between reading _owner and 
> _contentions in the is_async_deflating function. The
> loads re-ordering implies we could spuriously read an old value for 
> _owner (not deflating) and a new value for _contentions, leading it
> to believe it isn't deflating even though it is. But that is easier to 
> reason about because the loads are reading values written by the same 
> thread.
>

On that note, why does is_async_deflating() check both the _owner and 
_contentions? It requires both
to be updated to indicate deflation. But it seems to me that checking 
only _contentions is enough.

My understanding of the algorithm that making _contentions negative is 
the linearization point at which
we have decided that the monitor is async deflating and should no longer 
be used. The deflation marker
in the owner field is just the thing we poke in there before reaching 
the linearization point to force fast paths
that normally don't check _contentions to take a slow path instead, that 
checks it.

If _contentions < 0, then it is implied that _owner == deflating (and we 
assert that in some places).
It seems to me that the only thing checking the owner does here is to 
cause headache and spurious false
negatives due to requiring the careful fencing I described in order to 
return precisely the same result we
would get by looking only if the _contentions counter is negative. Or am 
I missing something? Is there a
valid case where the _contentions is negative, yet the _owner is not 
deflating, that we need to catch
and distinguish? I think not, and I worry about some other asserts if 
there truly is.

Thanks,
/Erik