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