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