RFR(T) 8240613 InstanceKlass::set_init_state failed with assert(good_state || state == allocated)

[Ioi Lam]

Thanks Dan for the review. I ran my changes with hs-tier1/2/3 and there 
are no failures. I am pushing now.

Thanks
- Ioi

On 3/8/20 6:06 AM, Daniel D. Daugherty wrote:
> On 3/8/20 9:04 AM, Daniel D. Daugherty wrote:
>> On 3/8/20 3:17 AM, Ioi Lam wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8240613
>>> http://cr.openjdk.java.net/~iklam/jdk15/8240613-set-init-state-graal.v01/ 
>>>
>>
>> src/hotspot/share/classfile/systemDictionary.cpp
>>     Looks like your intended partial backout of JDK-8240244 is correct.
>>
>> Please do a Tier1 sanity check run before you push.
>>
>> Thumbs up.
>
> And I agree that this is a trivial fix.
>
> Dan
>
>
>>
>> Dan
>>
>>
>>>
>>> In JDK-8240244 (Avoid calling resolve_super_or_fail in 
>>> SystemDictionary::load_shared_class) I added code to check if a 
>>> super type of a CDS shared class is already loaded. Apparently this 
>>> check, which takes the SystemDictionary_lock, causes a race 
>>> condition during class loading, and leads to the assert.
>>>
>>> So far the assert has happened only when graal is used as the JIT, 
>>> but I think that's just because when graal starts up, it initializes 
>>> many system classes in parallel to the main app, which increases the 
>>> likelihood of the race condition.
>>>
>>>
>>> I am not backing out JDK-8240244 entirely, because new code has been 
>>> pushed which depends on some of the cleanups done in JDK-8240244. 
>>> Instead, I am removing the most suspicious part of JDK-8240244.
>>>
>>> The assert would happen intermittently, but at least once in a 
>>> couple of hs-tier3-graal.js
>>>
>>> I am running hs-tier3-graal.js six times and the assert no longer 
>>> happens, so I think the fix is good.
>>>
>>> Thanks
>>> - Ioi
>>
>