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

[Mikael Gerdin]

Thomas,

On 2013-03-14 09:28, Thomas Schatzl wrote:
>
> 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.

The code looks like it does what you describe :)

Since the arguments parsing code is kind of hard to follow IMO and 
seemingly hard to get right it might be a good idea to write a 
regression test for this.

Just writing a short jtreg test to launch vms with these arg 
combinations that you described above and verify that we get the 
expected outcome should not be too much code with the ProcessTools test 
library.

/Mikael

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