RFR: Enable biased locking for Shenandoah by default

[Aleksey Shipilev]

On 11/20/2017 03:32 PM, Andrew Haley wrote:
> On 20/11/17 14:21, Aleksey Shipilev wrote:
> OK.  I guess it depends on how much, in a practical test, biased lock
> revocation affects our wort-case pause times.

Biased locking hiccups are transient, until Hotspot machinery understands which types are contended
too much. The revocation itself is not costly. Most of the cost is the global safepoint, and so
biased lock revocation is closer to our shallowest pause. I would guess that thread-local handshakes
in jdk10 would eliminate that cost.

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

Comes down to this: we are mildly okay with enabling other VM features that improve latency profile
without sacrificing throughput too much. So biased locking was disabled until we find the compelling
counter-example. Today is the day for specjvm counter-example (along other adopters' reports), so
that option goes back to default value.

Thanks,
-Aleksey