RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking
David Holmes
david.holmes at oracle.com
Mon Nov 18 11:27:41 UTC 2019
Hi Andrew,
On 18/11/2019 8:03 pm, Andrew Haley wrote:
> On 11/16/19 2:15 AM, Patricio Chilano wrote:
>> Biased locking will be disabled by default and all related flags will be
>> deprecated. Performance gains seen when the feature was introduced in
>> the VM are less clear today with modern Java code/processors. Detailed
>> rationale behind the change is included on the description of the bug.
>
> IMO detailed rationale on its own isn't going to do it. I would
> expect to see detailed measurements to justify such an important
> change rather than mere assertions. What do your numbers look like?
>
> This paragraph is rather incredible: "The performance gains that were
> seen in the past are far less evident today. The cost of executing
> atomic instructions has decreased on modern processors since the
> introduction of biased locking into the VM"
>
> This test, with no contention:
>
> @Benchmark
> public void lock(BenchmarkState state) {
> synchronized(state) {
> state.n++;
> }
> }
>
> Benchmark Mode Cnt Score Error Units
>
> -XX:+UseBiasedLocking:
> Dummy.lock avgt 3 2.063 ± 0.215 ns/op
>
> -XX:-UseBiasedLocking:
> Dummy.lock avgt 3 14.991 ± 0.365 ns/op
>
> Threadripper 2950X, 3.5Ghz.
>
> I believe that the uncontended case for synchronized blocks is still
> important.
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.
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?
Cheers,
David
-----
More information about the hotspot-runtime-dev
mailing list