[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 shenandoah-dev
mailing list