-
Bug
-
Resolution: Fixed
-
P2
-
8u131, 9
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8179757 | 10 | Kim Barrett | P2 | Resolved | Fixed | b07 |
JDK-8189494 | 8u172 | David Holmes | P2 | Resolved | Fixed | b01 |
JDK-8188683 | 8u171 | David Holmes | P2 | Resolved | Fixed | master |
JDK-8189529 | 8u162 | David Holmes | P2 | Resolved | Fixed | b02 |
JDK-8183670 | 8u161 | David Holmes | P2 | Resolved | Fixed | b01 |
JDK-8179469 | 8u152 | David Holmes | P2 | Resolved | Fixed | b04 |
JDK-8185307 | 8u151 | David Holmes | P2 | Closed | Fixed | b07 |
JDK-8192232 | emb-8u161 | David Holmes | P2 | Resolved | Fixed | b01 |
JDK-8185726 | emb-8u151 | David Holmes | P2 | Resolved | Fixed | b07 |
JDK-8193948 | openjdk7u | David Holmes | P2 | Resolved | Fixed | master |
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
FULL OS VERSION :
Mac OS X Sierra 10.12.4
Darwin ID-PC14001.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64
A DESCRIPTION OF THE PROBLEM :
When specifying -XX:+AggressiveHeap as JVM argument the VM now aborts with an error message . This used to work perfectly fine in all previous versions of the JRE/JDK
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
REGRESSION. Last worked in version 8u121
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
In the simplest form even this command line aborts
"java -XX:+AggressiveHeap -version" with error message
"The Parallel GC can not be combined with -XX:ParallelGCThreads=0"
In previous versions this simple cmd line would print the version. But any other combination doesn't work either.
Additionally trying to use PrintFlagsFinal to check the actual value still causes the error.
Many products ship with the setting in some config file out of the box (as do our own when set to production level during install)
PrintFlagsFInal confirms that it was using 8 threads on my machine prior to u131.
EXPECTED VERSUS ACTUAL BEHAVIOR :
That the virtual machine starts up with AggressiveHeap enabled without error
ERROR MESSAGES/STACK TRACES THAT OCCUR :
"The Parallel GC can not be combined with -XX:ParallelGCThreads=0"
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
java -XX:+AggressiveHeap -version
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
You can work arround this by explicitly specifying a value for ParallelGCthreads only if that argument is earlier in the argument list than AggressiveHeap.
But having to figure out why certain services/java based apps no longer start and having to edit the config files in the right location and order is annoying at best.
- backported by
-
JDK-8179469 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8179757 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8183670 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8185726 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8188683 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8189494 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8189529 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8192232 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8193948 HotSpot VM fails to start when AggressiveHeap is set
- Resolved
-
JDK-8185307 HotSpot VM fails to start when AggressiveHeap is set
- Closed
- duplicates
-
JDK-8187900 JRE fails to start by only specifying -XX:+AggressiveHeap
- Closed
- relates to
-
JDK-8147910 Cache initial active_processor_count
- Resolved