RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking

[Andrew Dinn]

On 18/11/2019 12:57, Aleksey Shipilev wrote:
> If you want to say that SPECjbb2015 does not show improvement, then that is because we (well, me
> myself!) specifically argued during its development that the lock usages there should explore
> something beyond biased locking. Which is why locking paths there are more or less contended, so
> that locks get out of their biased state. Therefore, arguing that biased locking is not needed
> because SPECjbb2015 does not show the benefit of having it enabled -- is circular.

I think that comment definitely constitute's shooting someone's fox
(i.e. the excu^H^H^H^H rationale offered for this action has just been
erased).

>> We'd like to know the impact on real applications but we have no way to know that a-priori. So we're
>> either stuck with the burden of supporting biased-locking forever, or we flip the switch to turn it
>> off and see if it causes too many issues. Unless you see another way to determine this?
> . . .
> At very least, deprecating the flag is unwarranted at this point, until we are totally sure it is
> not needed. You could make it disabled by default and collect complaints, though. That would take a
> few short-term releases for most interested parties to catch up with this.

That was my immediate thought in response to the above. Why would you
rush to deprecate (and eventually /remove/) something you still don't
know the true merits of? That doesn't engender confidence that this has
been thought through properly or decided rationally. Combined with
Aleksey's revelation above I think the the justification for adopting
this 'fix' requires a reboot, preferably from cold.

> Over and out. Don't rush this, please.
Agreed.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill