RFR: Enable biased locking for Shenandoah by default

[Christine Flood]

I'm all for keeping defaults the same across collectors unless there is a
very compelling reason not to.




Christine

On Mon, Nov 20, 2017 at 9:39 AM, Aleksey Shipilev <shade at redhat.com> wrote:

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