-
Enhancement
-
Resolution: Fixed
-
P4
-
8, 11, 17
-
b23
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8276627 | 11.0.14 | Aleksey Shipilev | P4 | Resolved | Fixed | b02 |
This is mostly motivated by JDK-8267241, but has an additional bonus of harmonizing the test configurations across components.
Current JTReg defaults to -Xmx512m, with two exceptions:
- hotspot does not set default heap at all (AFAICS, relying on MaxRAMPercentage and explicit heap sizes instead);
- langtools set it to -Xmx768m
I would propose to bump the default limit to 768m, and drop the langtools exception that is now subsumed by new default. The fact that there seem to be no complaints in running heavily-parallel langtools tests with -Xmx768m hopefully tells us that heavily-parallel jdk tests would survive too.
Current JTReg defaults to -Xmx512m, with two exceptions:
- hotspot does not set default heap at all (AFAICS, relying on MaxRAMPercentage and explicit heap sizes instead);
- langtools set it to -Xmx768m
I would propose to bump the default limit to 768m, and drop the langtools exception that is now subsumed by new default. The fact that there seem to be no complaints in running heavily-parallel langtools tests with -Xmx768m hopefully tells us that heavily-parallel jdk tests would survive too.
- backported by
-
JDK-8276627 Bump global JTReg memory limit to 768m
- Resolved
- relates to
-
JDK-8267241 java/time/format/TestZoneTextPrinterParser.java runs in too tight heap
- Closed
- links to
-
Commit openjdk/jdk11u-dev/1ae15632
-
Commit openjdk/jdk/e749f75d
-
Review openjdk/jdk11u-dev/575
-
Review openjdk/jdk/4087
(1 links to)