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

[Roman Kennke]

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
> 
>