-
Bug
-
Resolution: Fixed
-
P3
-
8, 9
-
b97
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8149233 | 8u101 | Zoltan Majo | P3 | Resolved | Fixed | b01 |
JDK-8144482 | 8u92 | Zoltan Majo | P3 | Resolved | Fixed | b02 |
JDK-8155329 | emb-8u101 | Zoltan Majo | P3 | Resolved | Fixed | b01 |
jdk 7 uses about 550 mb of memory
jdk 8 goes up to 1.5 gb of memory
The issue seemed to be that with tiered compilation and many compiler threads, we compiled a lot more methods in JDK 8 which lead to a lot bigger native memory footprint.
The native memory usage was reduced by running with:
-XX:CICompilerCount=2' -XX:-TieredCompilation -XX:CompileThreshold=80000 -XX:ReservedCodeCacheSize=48m
We never tried each of these flags separately in order to find out which gave the biggest impact.
We should look over if any of our default values gets too big on large machines with a lot of memory and CPUs.
- backported by
-
JDK-8144482 Compiling methods generated by Nashorn triggers high memory usage in C2
-
- Resolved
-
-
JDK-8149233 Compiling methods generated by Nashorn triggers high memory usage in C2
-
- Resolved
-
-
JDK-8155329 Compiling methods generated by Nashorn triggers high memory usage in C2
-
- Resolved
-
- relates to
-
JDK-8058148 MaxNodeLimit and LiveNodeCountInliningCutoff should be increased
-
- Closed
-
-
JDK-8143321 Reduce the C2 compiler's memory usage
-
- Closed
-
-
JDK-8131702 PhaseIterGVN(PhaseGVN* gvn) constructor can consume a lot of memory during incremental inlining.
-
- Closed
-
-
JDK-8201516 DebugNonSafepoints generates incorrect information
-
- Resolved
-
-
JDK-8011858 Use Compile::live_nodes() instead of Compile::unique() in appropriate places
-
- Resolved
-