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

Daniel D. Daugherty daniel.daugherty at oracle.com
Sun Mar 8 13:06:47 UTC 2020


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
>



More information about the hotspot-runtime-dev mailing list