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

Aleksey Shipilev shade at redhat.com
Wed Apr 22 13:16:51 UTC 2020


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.

1833 void ShenandoahHeap::op_strong_roots() {
1834   assert(is_concurrent_strong_root_in_progress(), "Checked by caller");
...
1837   set_concurrent_strong_root_in_progress(false);

*) 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     }

*) Double new-line here:

2916   try_inject_alloc_failure();
2917   op_class_unloading();
2918 }
2919
2920


-- 
Thanks,
-Aleksey



More information about the shenandoah-dev mailing list