RFR: Enable biased locking for Shenandoah by default

[Andrew Haley]

On 20/11/17 14:21, Aleksey Shipilev wrote:
> On 11/20/2017 03:11 PM, Andrew Haley wrote:
>> On 20/11/17 12:01, Aleksey Shipilev wrote:
>>> Few thoughts here:
>>>
>>>  *) Biased locking is inherently orthogonal to GC code, and is not visible even in gross GC pauses.
>>> Therefore, we have no observable improvements, as far as GC logging is concerned. (This is different
>>> for loop strip mining, that does improve gross pause times);
>>>
>>>  *) With the throughput hit we observe, it makes less sense to focus on orthogonal VM pauses.
>>
>> But biased-locking revocation does affect pause times. 
> 
> Not GC pauses though. Biased locking revocation is one of many
> _non-GC_ VM operations that may introduce latency hiccups.

Well, yes, obviously, but I don't understand why that is relevant.

>> Do we know how the worst-case pause times with Shenandoah's
>> CG-related pauses compare with revocation pauses?
>
> I think with large throughput hits that is mostly irrelevant.

> We disabled biased locking because throughput hits were minimal, and
> it improved the overall latency profile. This is mentioned on our
> Wiki as one of the suggested non-GC tunings. Now we see it hits
> throughput quite hard on some examples, and thus it invalidates one
> of the original conditions. Shenandoah still has the throughput hit
> budget to follow, and enabling something that depletes it completely
> is odd.

OK.  I guess it depends on how much, in a practical test, biased lock
revocation affects our wort-case pause times.

> It also makes Shenandoah better lined up for throughput comparisons
> against other collectors.

That's true: it is odd that enabling Shanandoah affects non-GC things
too.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671