RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking
Aleksey Shipilev
shade at redhat.com
Mon Nov 18 12:57:04 UTC 2019
(lurking off the parental leave to point out a few things) (...and resending with proper email)
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.
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.
> 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.
--
Thanks,
-Aleksey
More information about the hotspot-runtime-dev
mailing list