RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM
tao.mao at oracle.com
Wed Mar 13 12:15:20 PDT 2013
BTW, upon completion of this CR, please also investigate a CR with
similar problems (most likely, close as a duplicate) .
Please see inline.
On 3/13/13 6:17 AM, Thomas Schatzl wrote:
> Hi all,
> please review the following change which improves ergonomic heap
> sizing. Automatic heap sizing now takes available virtual memory into
> The problem occurred when the user reduced the available virtual memory
> via e.g. ulimit. As ergonomics did not take virtual memory into account,
> using available physical memory only, the vm typically crashed at
> This patch does not avoid all crashes due to out of virtual memory,
> because only heap sizing now takes available virtual memory into account
> now. Some GCs, and also other parts of the VM, try to reserve hundreds
> of MB at startup.
I don't quite understand what you mean here. Does it indicate that the
default value (i.e. 2) chosen for MaxVirMemFraction is a bit large?
(when it has the effect of limiting the head size, the virtual memory
would be small already.)
> The main change is in Arguments::allocatable_physical_memory() (which
> has been moved from the os class) where if an additional virtual memory
> limit has been imposed on the java process, the given heap size is
> bounded by a fraction of that limit.
It kind of violates parallelism here, for
Arguments::allocatable_physical_memory() and os::physical_memory() are
now defined in different classes while they should have the same level
of abstraction. Seems better to keep allocatable_physical_memory() back
in os due to its closeness to os.
> That fraction is determined by a new global called MaxVirtMemFraction
> (default value: 2).
follow the style
1946 product(uintx, MaxRAMFraction, 4, \
1947 "Maximum fraction (1/n) of real memory used for maximum heap " \
1948 "size") \
would be reasonable to phrase the definition similarly, say,
1961 product(uintx, MaxVirtMemFraction, 2, \
1962 "*Maximum* fraction (1/n) of virtual memory used for*maximum* heap size") \
> Some discussion points:
> - maybe make MaxVirtMemFraction at least notproduct. It does not seem
> to make much sense to expose that global to the end user, does it? If
> the user is able to change MaxVirtMemFraction, he/she may as well set an
> appropriate maximum heap size with the same effect.
> - in the OS specific implementations I kept the code duplication for
> the unix targets (bsd, linux, solaris) as it has been before. I think
> there is some effort for that going on already.
> - also in 32 bit implementations, the previously used heuristically
> found out virtual memory limits (around ~3.8GB) were kept.
> - for querying the virtual memory limit I used getrlimit() with
> RLIMIT_AS as parameter. In Solaris there is also RLIMIT_VMEM. Searching
> in opensolaris code showed that RLIMIT_AS is just another name for
> RLIMIT_VMEM. Additionally, RLIMIT_AS is the only available parameter for
> getrlimit() of the two in the posix spec
> ( http://pubs.opengroup.org/onlinepubs/009696799/functions/getrlimit.html ). This could help later when/if merging the various Unixes.
> What do you think?
(1) you may want to rephrase the comment or delete it
2607 // Make sure that if we have a lot of memory we cap the 32 bit
2608 // process space. The 64bit VM version of this function is a nop.
2609 initHeapSize = allocatable_physical_memory(initHeapSize);
(2) I also prefer a pointer argument here. It's more readable to
recognize its intention of usage.
187 static bool has_allocatable_memory_limit(julong& limit);
> jprt, local testing with different ulimit values
Did you test out all(or, most) platform combinations
(solaris/bsd/linux/windows + 32/64 bit) to verify the current code can
get the right size of virtual memory?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev