RFR (S) 8232788: Move biased locking initalization

[coleen.phillimore at oracle.com]

Thanks David!
Coleen

On 10/23/19 7:46 PM, David Holmes wrote:
> On 23/10/2019 10:37 pm, coleen.phillimore at oracle.com wrote:
>> On 10/22/19 10:29 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> On 23/10/2019 5:54 am, coleen.phillimore at oracle.com wrote:
>>>> Summary: Move from before adding to the dictionary to during 
>>>> InstanceKlass construction, which occurs right before.
>>>
>>> Right before? I had trouble seeing where the IK was created relative 
>>> to the call to SD::update_dictionary. But I don't think it really 
>>> matters as long as the biased locking state is set before the new IK 
>>> gets added to the SD.
>>
>> Right.  The InstanceKlass is parsed or loaded from the shared 
>> archive, then added to the SD.   Nothing else gets to see the 
>> InstanceKlass until then.
>>
>>>
>>> But I don't understand the change to restore_shareableinfo. Where 
>>> would the biased locking state get set on that code path today?
>>
>> Today, it's updated in update_dictionary in the case where the klass 
>> is loaded from the shared archive.
>
> Okay. I can't track where update_dictionary gets called in relation to 
> the use of load_shared_class and the subsequent call to 
> restore_unshareable_info.
>
>>   With this simple change, it's done in the constructor and removing 
>> this code from SystemDictionary that shouldn't know anything about it.
>
> I agree SD shouldn't need to know about it.
>
> Thanks,
> David
>
>> Coleen
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Tested with tier1 all Oracle platforms, tier 2-3, linux-x64-debug, 
>>>> tier1 with -XX:BiasedLockingDelay=100, and gtest with 
>>>> -XX:-UseBiasedLocking.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8232788.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8232788
>>>>
>>>> Thanks,
>>>> Coleen
>>