JDK-8006088 : Incompatible heap size flags accepted by VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-01-11
  • Updated: 2023-08-21
  • Resolved: 2013-05-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other Other
8Fixed hs25Fixed hs25,openjdk7uFixed
Related Reports
Duplicate :  
JDK-6493335 - Mismatch between -Xm[sx] and verbose:gc output
Relates :  
JDK-8014058 - Regression tests for 8006088
Description
The flags -XX:MaxHeapSize and -XX:InitialHeapSize are not communicating enough with each other and they seem to have different lower limits. Some examples:

-XX:MaxHeapSize=4m -XX:InitialHeapSize=8m  -> Runs with a heap of almost 8M
-XX:MaxHeapSize=4m -XX:InitialHeapSize=4m  -> Will not start (Incompatible minimum and initial heap sizes specified)
-XX:MaxHeapSize=8m -XX:InitialHeapSize=4m  -> Will not start (Incompatible minimum and initial heap sizes specified)
-XX:MaxHeapSize=4m    -> Runs with a heap of 5M
-XX:MaxHeapSize=3m    -> Runs with a heap of 4M
-XX:MaxHeapSize=2m    -> Runs with a heap of 3M
-XX:InitialHeapSize=6m   -> Will not start (Incompatible minimum and initial heap sizes specified)
-XX:InitialHeapSize=7m   -> Runs with a heap of 8.2M
-XX:InitialHeapSize=8m   -> Runs with a heap of 8.875M

This is with Parallel GC. Other GCs behaves differently in some cases. G1 seems to be closest to working intuitively.
Comments
Regression test missing due to merge error. Delivered in CR 8014058.
17-05-2013
URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d17700c82d7d User: amurillo Date: 2013-05-10 22:17:21 +0000
11-05-2013
URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d17700c82d7d User: jwilhelm Date: 2013-05-06 17:37:25 +0000
06-05-2013
The attached file (XmsInitialHeapSizeErgo.html) compares the new and old behavior.
11-04-2013
Investigation of the parameter processing code showed that -Xms and -XX:InitialHeapSize and -Xmx and -XX:MaxHeapSize were handled inconsistently, i.e. not the same. Further, it seems that case 1 "-XX:MaxHeapSize=4m -XX:InitialHeapSize=8m -> Runs with a heap of almost 8M" was a conscious decision, ergonomics tries to make initial and max heap size consistent by eventually adapting maximum heap size. In case 4, 5, 6 the collector policy silently enforce their minimum heap size/alignment requirements. The cause for cases 2, 3, 7 is described above. For some reason -Xms and -XX:InitialHeapSize is handled differently. The actual heap used in case 8-9 depend on the application as the flag only sets minimum/initial heap size, not maximum, so this is not a bug. In this case the the collector policies also enforce minimum heap size (also) due to alignment requirements.
01-03-2013
After some discussion with jesper the expected behavior should be as follows: - if user specified arguments of one of Initial/Max - Heapsize conflict, give an error, i.e. Initial <= Max must hold true. - otherwise adapt the non-specified (default) argument values to the ones specified so that Initial <= Max holds true and the VM can start up.
28-02-2013