Timeline for BiasedLocking removal?

[patricio.chilano.mateo at oracle.com]

Hi Roman,

On 5/11/21 2:05 PM, Roman Kennke wrote:
> Good. Does obsoletion mean it can be removed altogether?
>
> If nobody's signed up for it yet, I could also handle the actual removal.
Yes, obsolete allows code associated with the flag to be removed from 
the codebase 
(https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process).
I plan to remove the code in JDK18 as discussed in 8256253 (I thought I 
was already assigned in the bug).

Thanks,
Patricio
> Thanks,
> Roman
>
>> JDK-8256425 Obsolete Biased Locking in JDK 18
>> https://bugs.openjdk.java.net/browse/JDK-8256425
>>
>> On 5/11/21 9:50 AM, Roman Kennke wrote:
>>> Hi Hotspot devs,
>>>
>>> what is the timeline for removing BiasedLocking altogether? Or have 
>>> we even agreed that we are going to remove it?
>>>
>>> I am asking because this affects how I'd move forward with Lilliput. 
>>> If I can ignore BiasedLocking because it'd be removed in, say, JDK 
>>> 18 anyway, then I believe I can come up with a relatively simple 
>>> implementation for 64bit header that should be possible to integrate 
>>> into JDK 18. That is, I put the (compressed) Klass* in the upper 
>>> bits of the header, also keep the hashcode in the header, and keep 
>>> everything else (locking, GC bits) as they are.
>>>
>>> With biased-locking, the Klass* would clash with the Thread* in the 
>>> upper bits. If we are not going to remove BiasedLocking anytime 
>>> soon, I would have to come up with a different plan.
>>>
>>> (Also, note that I expect the performance improvement of Lilliput to 
>>> outweight possible - and hopefully rare - biased-locking removal 
>>> regressions)
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> Roman
>>>
>>
>