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

David Holmes david.holmes at oracle.com
Thu Nov 28 12:41:36 UTC 2019


On 28/11/2019 8:27 pm, Andrew Haley wrote:
> On 11/27/19 9:08 PM, David Holmes wrote:
>> SPECjbb2015 was used as supporting evidence that a modern benchmark
>> that people like to measure and report is not impacted by this
>> change. As I now know there is a good reason for that. But if
>> SPECjbb2015 is somehow supposed to be representative of some class
>> of real applications then this also bodes well for those
>> applications.
> 
> I completely agree.
> 
> 
> However, so far we know that:
> 
> When uncontended, biased locking is almost an order of magnitude
> faster than un-biased locking.

Oaky, but lets be very clear about what "uncontended locking" is. We're 
not talking about infrequent multi-threaded access to a shared object 
such that there is no contention on the lock. We are talking about 
performing locking on an object that is never actually shared. As soon 
as another thread locks an object the bias is revoked and that is the 
end of BL for that object (modulo the special bulk revocation case).

> In a couple of benchmarks which use uncontended biased locking, the
> performance advantage it brings is 3% - 5%.

Yes, and? Benchmark results are only of interest if they are 
representative of real world code.

> ReentrantLocks are about the same speed as un-biased synchronized blocks.
> 
> Another claim -- which I make without any evidence -- is that there is
> a lot of old Java code out there.

Perhaps - no way to know. And some fraction of that may benefit from 
biased-locking. And some fraction of that may benefit so much that it is 
noticeable. And some fraction of that is important enough to someone 
that they flag the issue.

> 
> Like many others i would love to be rid of biased locking, and I am
> perpetually disappointed by how effective it is.

Biased-locking is effective at what it does - that is not in dispute. 
What we are questioning is how much code really needs it today.

We will be stuck with it forever if we can't move forward somehow.

Cheers,
David



More information about the hotspot-runtime-dev mailing list