[15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope

Zhengyu Gu zgu at redhat.com
Wed May 20 18:42:48 UTC 2020


> 
> In push_evac_oom_scope, don't we want to assert that (level != sizeof(uint8_t)*8) or something? The
> overflow there would be catastrophic, right?
Sure.

diff -r 25dc6d2ed231 
src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp 
Wed May 20 13:28:17 2020 -0400
+++ b/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp 
Wed May 20 14:34:41 2020 -0400
@@ -159,6 +159,8 @@
    // Push the scope one level deeper, return previous level
    static uint8_t push_evac_oom_scope(Thread* thread) {
      uint8_t level = evac_oom_scope_level(thread);
+    // UINT_MAX = 255
+    assert(level < 254, "Overflow nesting level");
      data(thread)->_oom_scope_nesting_level = level + 1;
      return level;
    }


> 
> Actually, now that I think of it, wouldn't it be safer to make _oom_scope_nesting_level uint32_t,
> for example? That would be physically harder to overflow.Actually, this patch helps to workaround barrier problem, which forces 
us to 'flat' the scope. Logically, we should have at most 2 levels. Top 
level is setup by workers and the second level is setup by barrier.

Thanks,
-Zhengyu

> 
> Otherwise looks fine.
> 



More information about the hotspot-gc-dev mailing list