RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking
Thomas Stüfe
thomas.stuefe at gmail.com
Thu Nov 28 17:03:26 UTC 2019
Hi David,
On Thu, Nov 28, 2019 at 1:41 PM David Holmes <david.holmes at oracle.com>
wrote:
> 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.
>
>
I'm curious, has Oracle done some sort of market research to see the actual
impact this change would have? Or will the deprecation and
disabling-by-default of BL be the market research? And if yes, how would
you even get the result? Customers may see a performance regression without
ever attributing it to BL or without ever telling anyone about it, they may
just sigh and go back to earlier releases. And I would like customers to
have motivation to go to new releases, not to stay on old ones.
My gut feeling is that the vast majority of code in the field is legacy
code, and IMHO a good VM is one which runs legacy code well. Similar to the
Linux kernel which aims to "never break user space".
> We will be stuck with it forever if we can't move forward somehow.
>
> Cheers,
> David
>
>
Cheers, Thomas
More information about the hotspot-runtime-dev
mailing list