RFR: Enable biased locking for Shenandoah by default

[Aleksey Shipilev]

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.

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

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

Thanks,
-Aleksey