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

Thomas Schatzl thomas.schatzl at oracle.com
Tue Mar 26 06:56:23 PDT 2013


Hi,

On Mon, 2013-03-25 at 11:20 -0700, Jon Masamitsu wrote:
> On 3/25/13 2:24 AM, Thomas Schatzl wrote:
> 
> > Hi,
> > 
> > The current behavior, that -Xms sets both initial and minimum heap size
> > is very unsatisfying and not easily discoverable (which was the cause
> > for this CR). The order of switches would be important, in addition to
> > -Xms doing something unexpected. Additionally the initial/minimum heap
> > sizes are not synchronized, so a user also sometimes gets strange error
> > messages.
> > 
> > The documentation  for -Xms via java -X also contradicts (or at least
> > omits important information) both external documentation and actual
> > behavior.
>
> Since -Xms is a -X flag (e.g., is implemented by other
> JVM's) I've assumed that we are stuck with supporting the
> behavior as described.  If it's not specified, we have some
> flexibility.
> 
At http://cr.openjdk.java.net/~tschatzl/8006088/webrev.3 there is a new
webrev.

It keeps the behavior that -Xms unconditionally sets both minimum and
initial heap size. I could not find any document describing standard
behavior, and the current behavior has been that way in the VM since its
import into the current repository.

Apart from that, this change
- automatically adapts minimum heap size if only InitialHeapSize is
given. This additional code is now needed as InitialHeapSize and -Xms
have different behavior. Otherwise it is possible to get "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.
- improves the test cases (refactoring, new test cases)


If you don't pass either -Xms or InitialHeapSize, the minimum/inital
heap is ergonomically determined as before.

Testing: jprt, manual testing

Hth,
Thomas




More information about the hotspot-gc-dev mailing list