RFR (S): 8006088: Incompatible heap size flags accepted by VM

[Thomas Schatzl]

Hi all,

  please have a look at the following change which tries to make heap
size argument processing more intuitive.

Problem as stated in the CR is that -XX:MaxHeapSize and
-XX:InitialHeapSize are not communicating enough, so that the resulting
behavior is not intiutive.

The CR lists the different issues, grouping them in three categories:

1)

-XX:MaxHeapSize=4m -XX:InitialHeapSize=8m -> Runs with a heap of 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) 

The problem here was that after argument processing there was no
checking whether these two arguments contradicted each other.
Additionally there was some code that automatically increased
maxheapsize according to InitialHeapSize. The other two situations
occurred because setting of InitialHeapSize did not set the
internal minimum heap size (what the alternative, -Xms, did). So
the collector policy used a default value of NewSize + OldSize for
MaxHeapSize, which may be larger than the given InitialHeapSize
values (2).

2)
-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 

These situations occured for the generational collectors because the
collector policy overrode maxheapsize with the sum of newsize and
oldsize. If the default values of the latter were larger than the
specified MaxHeapSize, it adapted MaxHeapSize to be NewSize + OldSize.

-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 

Only the first one is a bug. This is due to -XX:InitialHeapSize not
setting the internal minimum heap size. I.e. same as for the cases in
1). Note that with -Xms (which is the equivalent switch) the VM
started up.

The second two are no bugs imo as the user did not mention a bound for
the maximum heap size in the arguments, so it would be free to choose
anything >= InitialHeapSize.


Webrev:
http://cr.openjdk.java.net/~tschatzl/8006088/webrev/

The problem with the VM starting up when InitialHeapSize > MaxHeapSize
is fixed in the first hunk of collectorPolicy.cpp where the respective
sanity check has been added.

The change for the "incompatible minimum and initial heap size is located
in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the
same as -Xms and -XX:MaxHeapSize the same as -Xmx.

The latter for consistency (using the same code path for -Xmx and
-XX:MaxHeapSize), as at the moment it does not set any internal variables.

The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp
where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize
has been set on the command line, New- and OldSize are shrunk to fit.

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-8006088

CR:
http://bugs.sun.com/view_bug.do?bug_id=8006088

Testing:
JPRT, manual testing of above test cases with all collectors with
"java -version".

Thanks,
Thomas