-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b12
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8240459 | 14.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b01 |
We have the block added to Shenandoah arguments code that adjust MaxNodeLimit and friends (predates inclusion of Shenandoah into mainline):
https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-August/006983.html
At the time, it was prompted by observing that lots of barriers everywhere really needed to have this limit bumped. Today, with simplified LRB scheme, more simple LRB due to SFX, etc, we do not need this.
The change above used ShenandoahCompileCheck, which made it into upstream code under generic AbortVMOnCompilationFailure. With that, I was able to verify that dropping the block does not yield compilation failures due to exceeded node budget on hotspot_gc_shenandoah, specjvm2008, specjbb2015. Performance numbers are also not affected (as expected).
Therefore, the adjustment can be removed.
https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-August/006983.html
At the time, it was prompted by observing that lots of barriers everywhere really needed to have this limit bumped. Today, with simplified LRB scheme, more simple LRB due to SFX, etc, we do not need this.
The change above used ShenandoahCompileCheck, which made it into upstream code under generic AbortVMOnCompilationFailure. With that, I was able to verify that dropping the block does not yield compilation failures due to exceeded node budget on hotspot_gc_shenandoah, specjvm2008, specjbb2015. Performance numbers are also not affected (as expected).
Therefore, the adjustment can be removed.
- backported by
-
JDK-8240459 Shenandoah: ditch C2 node limit adjustments
-
- Resolved
-