[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