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

[David Holmes]

Hi Thomas,

On 29/11/2019 3:03 am, Thomas Stüfe wrote:
> Hi David,
> 
> On Thu, Nov 28, 2019 at 1:41 PM David Holmes <david.holmes at oracle.com 
> <mailto: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? 

The disabling and deprecation would 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.

I can't see how to account for such people. I'm assuming most users 
don't fall into such a category and that as part of their evaluation of 
running their app on a new JDK release they care enough about 
performance to at least provide some feedback (and hopefully have the 
sense to read release notes).

> 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".

Is that 5 year old legacy code? 10 year? 15 year? 20 year? They are all 
potentially quite different.

This doesn't break functionality.

David
-----

>     We will be stuck with it forever if we can't move forward somehow.
> 
>     Cheers,
>     David
> 
> 
> Cheers, Thomas