Shenandoah: assert(klass->is_loader_alive()) failed: must be alive

[Zhengyu Gu]

Nevermind, failed in 32-bit JVM again. Sigh!

-Zhengyu


On 9/18/19 3:14 PM, Roman Kennke wrote:
> The locking in ShenandoahNMethodTable::register_nmethod() is dirty. I 
> would *very* much prefer to shuffle that code around to use scoped 
> lockers. It's also buggy, because there is an early return there, which 
> would miss the unlock. A way to do this would be to pull the disarm into 
> the if-else blocks, and put scope inside the if-else too.
> 
> Roman
> 
>> We have seen above assertion failures in shenandoah/jdk nightly tests 
>> periodically, especially after JDK-8230401.
>>
>> It actually became quite reproducible on my local machine with 
>> tier3_gc_shenandoah after JDK-8230401.
>>
>> The problem appears to be missing proper synchronization of metadata 
>> of newly registered nmethod.  Initially, I thought new nmethod is 
>> registered under CodeCahe_lock and concurrent codecache iteration 
>> always starts with acquiring CodeCache_lock lock. What I missed is 
>> that, the actual codecache iteration is done by worker thread, while 
>> the CodeCache_lock is acquired by VMThread. Therefore, it never 
>> establishes synchronization of newly created nmethod metadata 
>> (ShenandoahNMethod) between compiler thread (registering the nmethod) 
>> and worker thread (processing the nmethod).
>>
>> The solution is to always acquire per-nmethod lock when changing and 
>> iterating the metadata.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~zgu/shenandoah/assert_is_loader_alive/webrev.00/ 
>>
>>
>> Test:
>>    hotspot_gc_shenandoah (fastdebug and release)
>>
>>    hotspot_gc_shenandoah/tier3_gc_shenandoah (fastdebug) with 10+ 
>> iterations on my local machine and gotland respectively.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>