[15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading

[Zhengyu Gu]

On 4/22/20 9:16 AM, Aleksey Shipilev wrote:
> On 4/22/20 2:57 AM, Zhengyu Gu wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243323
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.00/index.html
> 
> *) This is awkward, why does it piggyback on is_concurrent_weak_root_in_progress? It should probably
> have its own flag, and that flag should only be set when SCR::should_do_concurrent_class_unloading()
> is true. Control thread should not drop the flag, it should be done by the relevant entry_*/op_* stage.
> 
> Also, double new-line at L367-368.
> 
>   360   // Perform concurrent class unloading
>   361   if (heap->is_concurrent_weak_root_in_progress()) {
>   362     if(ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) {
>   363       heap->entry_class_unloading();
>   364     }
>   365     heap->set_concurrent_weak_root_in_progress(false);
>   366   }
>   367
>   368
> 
> It is generally about symmetries. See how SH::op_strong_roots does it? New code should do the same.

Fixed.

> 
> *) Feels like this code belongs in shenandoahNMethods?
> 
> 1766     if (_concurrent_class_unloading) {
> 1767       MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 1768       _nmethod_itr.nmethods_do_begin();
> 1769     }
> 
> ...
> 
> 1775     if (_concurrent_class_unloading) {
> 1776       MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 1777       _nmethod_itr.nmethods_do_end();
> 1778     }
> 

This is the current usage pattern, shenandoahNMethods not taking any 
locks. If indeed need to be changed, should be a followup CR.


> *) Double new-line here:
> 
> 2916   try_inject_alloc_failure();
> 2917   op_class_unloading();
> 2918 }
> 2919
> 2920
> 
Fixed.

Updated:

http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.01/

Thanks,

-Zhengyu
>