Increase memory limits for IcedTea

[Andrew Haley]

Florian Weimer writes:
 > * Andrew Haley:
 > 
 > > OK, so it's your complaint that MAP_NORESERVE shouldn't reserve memory
 > > even if overcommit_memory = 2 ?  That isn't what the documentation
 > > says:
 > 
 > No, my complaint is that before you increase the default heap sizes, you
 > should make sure that you still can run a decent number of VMs in
 > parallel even if overcommit_memory = 2 is set.

I see.  The default heuristic for the parallel collector, as far as I
can tell from studying the code, seems to be to "probe physical memory
and use some reasonable fraction of the physical memory, up to a
maximum of 1GB."  The default value of this fraction is 1/4.  And, as
far as I can see, this overrides whatever default we set.

With parallel gc turned off my patch does make a difference, though.

 > > This suggests to me that in Mode 2 the system is doing what it's
 > > supposed to do.
 > 
 > Maybe.  In this case, Hotspot should use a different method to
 > reserve the address space.  My concern is that the PROT_NONE trick
 > works, but is (AFAIK) not documented, and might break in the
 > future.

Indeed it might.  Indeed, the PROT_NONE trick sounds like it behaves
in a way that is contrary to the specification.

>From a support point of view, the way that Java dynamically sets its
limits based on the capabilities of a particular box is quite scary.
I can certainly see why it's done, but it does mean that for
reproducible builds you have to find VM parameter that is set
dynamically and nail it down.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903