Biased locking Obsoletion

[David Holmes]

On 9/11/2020 7:44 pm, Andrew Haley wrote:
> On 11/8/20 10:04 PM, David Holmes wrote:
>> Hi Martin,
>>
>> On 7/11/2020 3:29 am, Doerr, Martin wrote:
>>> Hi Patricio,
>>>
>>> seems like nobody wanted to be the first person to reply. So I just share a few thoughts.
>>>
>>> Unfortunately, I haven't heard any feedback from end users.
>>> If the Biased Locking Code removal is not urgent because it's in the way for something else, I'd slightly prefer to remove it early in JDK17.
>>>
>>> My impression is that modern workloads are fine without BL, so typical JDK15 users will probably not notice it was switched off.
>>>
>>> Some old workloads are heavily affected, like SPEC jvm98. See performance drop on Power9:
>>> http://cr.openjdk.java.net/~mdoerr/BiasedLocking_Power9.png
>>> and on Intel Xeon E5:
>>> http://cr.openjdk.java.net/~mdoerr/BiasedLocking_XeonE5.png
>>>
>>> Are there any plans for mitigations?
>>
>> I don't see what mitigations are possible. We know that if you use
>> heavily synchronized code when it is not necessary (i.e. uncontended)
>> then BL shines at improving performance. Real "old" code would have been
>> updated years ago to move away from the synchronized library classes
>> (Vector, Hashtable) that typically result in these situations. Given
>> that we can't update things like SPEC jvm98, they will show lower
>> performance without BL. But I don't think we should care about this in 2020.
> 
> Well, we kind-of have to care, given that some of this "old" code that would
> have been updated years ago is still in core classes in the Java library.

I'm talking about caring about old code like SPECjvm98. The classes 
themselves are perfectly fine for MT situations. It is only ancient code 
that utilised them for single-threaded situations (and they had no 
choice prior to 1.2) that is impacted.

> JDK-8254078 is a simple example, and a very modest proposal for change,
> and it's still stuck in CSR.

It was approved on October 25.

David
-----