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

[Andrew Haley]

On 11/18/19 11:27 AM, 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.

I'm not really surprised. That's probably because modern benchmarks
are using ReentrantLocks, which are just as slow (or fast, choose your
poison) as monitors, but with no way to use biasing for uncontended
cases. So of course such benchmarks don't benefit from biased locking,
more's the pity.

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

Here's my completely unbiased (:-) take on it:

We're looking at a performance regression with nothing in return
beyond our own convenience. Which is nice (hey, I don't like that
biased locking code, either, I had to the stubs for AArch64 and they
gave me a headache) but I'm wondering who we should prioritize, us or
our users. And that is the choice, isn't it?

Sometimes I think we don't realize what we've got.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671