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

[Andrew Haley]

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.

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.
:-)

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