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

[Patricio Chilano]

Thanks all for chiming in to this one. I knew this was going to be a 
controversial patch and I really appreciate your feedback. The idea was 
also to get enough feedback to make the best decision and not just to 
push it without general consent.

@Aleksey,

On 11/18/19 7:55 AM, 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.
Yes, now we have TLH for bias revocations which allows us to avoid 
safepoints (except for the bulk ones). I run benchmarks (Specjbb2005, 
Specjbb2015, and Specjvm2008 on Linux and Windows) though and didn't see 
regressions nor improvements compared to when we used safepoints. With 
handshakes we don't have to stop all JavaThreads but it is still not 
cheap for the revocation itself (I've measured cases where the actual 
time to revoke with handshake was more than with safepoint). And today 
we still have to go through the VMThread which can be a bottleneck, 
although I'm working on 8230594 to allow direct handshakes between 
JavaThreads.

> 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.
Ok, I didn't really know the specifics of how SPECjbb2015 was designed. 
Yes, the measurements show no significant changes on that one. Here are 
some results running on a Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz 
processor for example:

Oracle Linux 6.4 criticaljOPS                                     maxjOPS
-XX:+UseBiasedLocking 22635.00                                    31012.00
-XX:-UseBiasedLocking 22885.00                                    31196.67
GNU/Linux 4.1.12
-XX:+UseBiasedLocking                                       24277.00    
                                  41571.00
-XX:-UseBiasedLocking 24583.00                                     41500.00

The benchmark was actually run several times with different tunning 
flags but the results are similar (thanks to Thomas Schatzl for running 
them! )

I did see a 2-3% regression on Specjbb2005 and some Specjvm2008 as you 
mentioned. But whenever there is a new patch we always seem to just rely 
on how Specjbb2015 performs, so that's why I assumed that maybe those 
benchmarks weren't that representative today.

>> 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
>
> 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.
Ok, yours and others concerns seem reasonable. I think I got enough 
feedback from this RFR. If we actually want to continue with this I'll 
start a JEP then.

Thanks!

Patricio
> -Aleksey
>