Biased locking Obsoletion

[David Holmes]

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.

Cheers,
David

> If so, it would be nice to implement them before finally removing BL.
> 
> My 0.02$.
> 
> Best regards,
> Martin
> 
> 
>> -----Original Message-----
>> From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
>> On Behalf Of David Holmes
>> Sent: Dienstag, 3. November 2020 22:30
>> To: Patricio Chilano <patricio.chilano.mateo at oracle.com>; hotspot-runtime-
>> dev at openjdk.java.net; hotspot-dev developers <hotspot-
>> dev at openjdk.java.net>
>> Subject: Re: Biased locking Obsoletion
>>
>> Expanding to hotspot-dev.
>>
>>
>> On 4/11/2020 7:08 am, Patricio Chilano wrote:
>>> Hi all,
>>>
>>> As discussed in 8231264, the idea was to switch biased locking to false
>>> by default and deprecate all related flags with the intent to remove the
>>> code in a future release unless compelling evidence showed that the code
>>> is worth maintaining.
>>> I see there is only one issue that was filed since biased locking was
>>> disabled by default (https://github.com/openjdk/jdk/pull/542) that seems
>>> to have been addressed. As per 8231264 change, the code was set to be
>>> obsoleted in 16, so we are already in a position to remove biased
>>> locking code unless there are arguments for the contrary. The
>>> alternative would be to give more time and move biased locking
>>> obsoletion to a future release.
>>> Let me know your thoughts.
>>>
>>> Thanks,
>>>
>>> Patricio