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

[Robbin Ehn]

Hi,

On 2020-02-12 15:50, Andrew Haley wrote:
> On 2/11/20 6:35 PM, Man Cao wrote:
> 
>> We are concerned about the deprecation of biased locking, so we
>> asked a colleague (Fred Kuipers <fredjk at google.com>) to help us
>> experiment with -XX:-UseBiasedLocking on an important production
>> service.  Overall, the results are supportive of disabling
>> UseBiasedLocking.
>>
>> The experiments are based on JDK 11.0.5 running with G1 and
>> -XX:-TieredCompilation on x86_64-based Linux.  There are 7 servers
>> for the service, with heap sizes ranging 3G-15G, serving real
>> production traffic.  Production traffic is split into two shards for
>> each server, one shard running with -XX:+UseBiasedLocking, the other
>> with -XX:-UseBiasedLocking. The production team uses the exact same
>> methodology to evaluate performance issues in their routine release
>> process.
>>
>> 3 out of the 7 servers see no difference. The other 4 servers see
>> potential improvement (reduction) in CPU usage with
>> -XX:-UseBiasedLocking. This would translate to improved throughput
>> for us.
> 

Yes, thanks a lot!

> Thank you for that. Haing discussed this with several people, it seems
> that although biased locking still helps in the purely uncontended
> case with empty loops, this isn't representative of real-world
> applications. Also, more applications are using j.u.c. Locks so
> the importance of synchronized blocks is declining, particularly
> in the context of Project Loom.
> 
> So, I'm happy to withdraw my objection. We could proceed to disabling
> biased locking by default, and gather some data from users. IMO, YYMV.
> :-)
> 

Change default value in 15 and potentially deprecate in 16,
is that what we have consensus on?

Thanks, Robbin