Biased locking Obsoletion

[Andrew Haley]

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.

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

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671