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

[David Holmes]

Hi Aleksey,

On 18/11/2019 10:55 pm, Aleksey Shipilev wrote:
> (lurking off the parental leave to point out a few things)
> 
> There way too few details in the RFE report to make the informed decision. Also, removing it when
> thread-local handshakes are finally there to make unbiases/rebiases much less painful for
> performance is quite odd to see.

I'm not sure where TLH stands in relation to biased-locking at this 
stage. I think it is partly the work on trying to use TLH that 
motivated seeing if we can just remove biased-locking altogether.

> On 11/18/19 12:27 PM, David Holmes wrote:
>> For a micro-benchmark like that sure. But is that at all representative of real modern code? We know
>> some of the really old benchmarks used synchronized collections and StringBuffer extensively and so
>> they also benefit from biased-locking. But more modern benchmarks are not showing any benefit.
> 
> 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.

As I have no knowledge of how any of these benchmarks are designed or 
what they are intended to try and demonstrate I can't really comment. I 
personally loathe the silly benchmark dances that we do trying to 
convince people that if benchmark X runs well then so will some set of 
real applications. But if the current benchmark people are caring about 
is specjbb2015 then it apparently runs better without biased-locking.

>> 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?
> 
> We (in Shenandoah) were back and forth on heuristically enabling/disabling UseBiasedLocking. When we
> did disable it by default, we had users complain about performance penalties against other
> collectors. Which lead us to reinstating it back, and it was also visible on some SPECjvm2008
> benchmarks:
>    http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-November/004333.html

The discussion is very similar to the to-and-fro we have also had in 
Oracle over the past couple of years. Some benchmarks show benefit from 
biased-locking because they (over?) use uncontended locking which is 
exactly what biased-locking was designed to cheapen. But do we care 
about such benchmarks? Do they tell us anything interesting about the 
impact on real applications?

Can you share which users complained, and for what applications?

> 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.
> 
> Over and out. Don't rush this, please.

Well as I said we've already been sitting on this for quite a while. :)

Thanks,
David
-----


> -Aleksey
>