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

[Man Cao]

Hi,

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.

-Man


On Thu, Jan 2, 2020 at 11:27 AM Florian Weimer <fw at deneb.enyo.de> wrote:

> * Andrew Haley:
>
> > On 11/27/19 10:30 PM, Florian Weimer wrote:
> >> If biased locking were determined important to JNI code, it would be
> >> interesting to consider how its performance gains relate to the
> >> general JNI overhead.
> >
> > JNI overhead is significant, partly because of the need for the
> > VM-native state changes to be atomic. I don't think a couple of CAS
> > operations will make a large difference.
>
> I see.  Is critical JNI still unsupported?
>
> It's also not clear that synchronization around JNI is common outside
> the JDK itself.
>