JDK-8231264 : Implementation of JEP 374: Disable biased-locking and deprecate all flags related to biased-locking
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
Changed the synopsis to match the more usual pattern for issues related to JEPs. We can fill in the number once the JEP is accepted.
Discussion related to this RFE:
Some results of performance testing at Google:
On 2/11/20 1:35 PM, Man Cao wrote:
> We are concerned about the deprecation of biased locking, so we asked a
> colleague (Fred Kuipers <firstname.lastname@example.org>)
> to help us experiment with -XX:-UseBiasedLocking on an important production
> 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
Reopen based on [~dcubed] comments. We can still use this RFE.
[~pchilanomate] - you can file a JEP and still use this bug as the implementation RFE...
I recommend reopening this bug.