RFR (S): 8006088: Incompatible heap size flags accepted by VM
John Cuthbertson
john.cuthbertson at oracle.com
Mon Apr 15 23:29:06 UTC 2013
Hi Thomas,
Why do we treat:
java -Xms8M -XX:InitialHeapSize=4M...
as an error while accepting:
java -XX:InitialHeapSize=4M -Xms8M...
It looks inconsistent. In both cases the user has asked for an initial
heap size less than his requested minimum.
In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be
coalesced into a single line for each? This would make the setting of
Initial and Min consistent with the code that sets Max on line 87.
Other than these nits - it looks good to me. Very exhaustive test case.
JohnC
On 4/11/2013 6:33 AM, Thomas Schatzl wrote:
> Hi all,
>
> there is a new webrev for this issue at
> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/
>
> Since it has been a while since the last update, here is a short
> introduction to the problem again:
>
> The current argument processing for minimum, initial and maximum heap
> sizing is somewhat unintiutive.
>
> This CR tries to fix and improve it.
>
> The following problems have been identified and fixed with earlier
> webrevs (as of http://cr.openjdk.java.net/~tschatzl/8006088/webrev.3):
>
> - VM gives an error when InitialHeapSize > MaxHeapSize
> - shrink NewSize and OldSize so that if MaxHeapSize is given, their sum
> is below MaxHeapSize.
> - automatically adapt minimum heap size if only InitialHeapSize is
> given. This avoids getting "Incompatible minimum and initial heap sizes
> specified" if only -XX:InitialHeapSize is specified with low values.
> - also allow specification of -Xms0 (i.e. size >= 0, not size > 0); this
> is a valid heap size specification, and means minimum/initial heap size
> = OldSize + NewSize.
> - test cases
>
> The new additions for this webrev are as follows:
>
> - implement the behavior shown in the table at
> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/XmsInitialHeapSizeErgo.html . This table also shows old behavior for comparison with the new behavior. Summarizing, this changeset fixes unexpected errors in the old behavior in the case when:
> * -Xms0 is given,
> * only -XX:InitialHeapSize=0 is given (previously the resulting
> initial heap size was OldSize + NewSize while now it applies normal
> ergonomics), and
> * when setting -Xms to a "large" value and -XX:InitialHeapSize to
> zero. (Only this issue had to be actually fixed in comparison to the
> earlier webrev).
> - add new jtreg tests for previously unverified behavior of that entire
> table.
> - improved testing for maximum heap sizing which now does not rely on a
> hardcoded constant for aligning the expected value as the test case
> retrieves the alignment value from the VM.
>
> Bugs.sun.com:
> http://bugs.sun.com/view_bug.do?bug_id=8006088
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8006088
>
> Testing:
> jprt, manual invocation of all test cases
>
> Hth,
> Thomas
>
>
>
More information about the hotspot-gc-dev
mailing list