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

[Jon Masamitsu]

On 3/25/13 2:24 AM, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2013-03-22 at 15:23 -0700, Jon Masamitsu wrote:
>> This comment is only correct if InitialHeapSize is not set on the
>> command line or at least that's  my understanding.
>>
>> 2355       // Currently the minimum size and the initial heap sizes are the same.
>>
>> Until InitialHeapSize was introduced, the initial heap size was the
>> minimum heap size.
> The implementation unconditionally sets both minimum and initial heap
> size to the given value. The change only adds this comment (for
> clarification that this has been an intentional decision).
After this change (adding InitialHeapSize)

2342     } else if (match_option(option, "-Xms", &tail) || match_option(option, "-XX:InitialHeapSize=", &tail)) {


will there be a change in behavior when InitialHeapSize is set on the
command line?  Seems to me

With change, InitialHeapSize becomes the minimum heap size.

>
> I looked a little more into how -Xms is documented, and I actually found
> conflicting information:
>
> java -X output:
> -Xms<size>       "set initial Java heap size"

So the above matches the current behavior, yes?
>
> Oracle documentation:
>
> "-Xms is minimum heap size (only)"
>
> http://docs.oracle.com/cd/E15523_01/web.1111/e13814/jvm_tuning.htm

The above is for jdk 5.
> http://docs.oracle.com/cd/E19528-01/819-4742/abeik/index.html

Don't know about this one above.
> http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#generation_sizing

Jdk 6 tuning guide so doesn't have the InitialHeapSize flag (I believe).
> http://docs.oracle.com/cd/E19528-01/819-4742/abeik/index.html

Don't know about this one above.

>
> and
>
> InitialHeapSize documentation:
>
> "Initial heap size (in bytes); zero means OldSize + NewSize"
>
> Other documentation gathered from searching the web, paraphrasing:
>
> "Minimum heap size cannot be set, only initial heap size.", and the
> general recommendation to set -Xms to -Xmx.

Don't recognize the above recommendation.  Hope I didn't make it.
>
>
> Since the documentation for both -Xms and InitialHeapSize match, this
> change modifies the code so that they use the same implementation.
> Assuming that the in-product documentation is the most current/valid
> one; I did not consider searching specifically for oracle documentation
> at that time.
>
>> Sometime during jdk7 development the default heap size for the
>> client VM was changed to use the same (or at least similar ergonomics
>> heap sizing as with the server VM) with the exception of windows
>> (maybe, not sure about the windows exception).
> I cannot find a Windows exception, but maybe I overlooked that. I will
> have another look.

There has in the past been an exception for windows that
regardless of the memory size and number of cpus, windows
machines were never "server class machines".  I would have thought
that this same exception would have been made for sizing the
heap using the GC ergonomics.  That was only for 32 bit windows.
>
>> The minimum heap size was not changed as far as I know. Part of
>> the ergonomics heap sizing is that the initial heap size is calculated
>> and is not the minimum heap size.  The motivation for the initial heap
>> size change was faster start up (didn't have to go through GC's to get
>> a bigger heap).  The motivation for the client VM using the ergonomics
>> heap sizing was easy of use.  With the minimum heap size staying the
>> same, if the application did not need a heap that was as large as the
>> initial heap size,  the heap sizing would shrink the heap back down.
>> That way any footprint increase would be transitory at start up
>> and the heap size would evolve to what it had been before (was the hope).
>>
>> The actual flag InitialHeapSize was introduced to give the user some
>> control over the InitialHeapSize if such control was really needed but
>> I don't think it was supposed to affect the minimum heap size.
> I understand the motivation of having a separate control to set the
> minimum and initial heap size.
>
> However the implementation and the documentation of these switches
> contradict to some degree.
>
> What is the expected behavior?

My expectation is that InitialHeapSize sets a value that is different
from the minimum heap size.  That the minimum heap size be the
same as in jdk6.  That with jdk7 an initial heap size can be set or
ergonomically calculated such that it is larger than the minimum.
That sizing policy in the collectors shrink the size of the heap
to its jdk6 minimum if the larger initial heap size is not needed.
>
> One suggestion:
>
>   -Xms    sets only minimum heap size (and automatically adjust
> InitialHeapSize if not set manually; verify otherwise). Also change the
> documentation string.
Automatically adjust InitialHeapSize how?

>
>   -XX:InitialHeapSize sets only initial heap size; if set on command
> line, check validity against minimum heap size at some point. Otherwise
> adapt to detected minimum heap size setting. If -Xms is not set, set
> minimum heap size to the same value.

The jdk6 minimum heap size (no flags on the command line) was
about 4m.  If the is not using its heap (releases lots of space and
does a System.gc() for example), I think the size of the heap should
shrink back down to something approaching this size.

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

Jon
>
> What do you think?
>
> Thanks for looking at that,
> Thomas
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130325/5ad2552c/attachment.htm>