RFR (S): 8006088: Incompatible heap size flags accepted by VM
thomas.schatzl at oracle.com
Mon Mar 25 02:24:27 PDT 2013
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).
I looked a little more into how -Xms is documented, and I actually found
java -X output:
-Xms<size> "set initial Java heap size"
"-Xms is minimum heap size (only)"
"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.
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.
> 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?
-Xms sets only minimum heap size (and automatically adjust
InitialHeapSize if not set manually; verify otherwise). Also change the
-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 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
The documentation for -Xms via java -X also contradicts (or at least
omits important information) both external documentation and actual
What do you think?
Thanks for looking at that,
More information about the hotspot-gc-dev