Increase memory limits for IcedTea

[Andrew Haley]

Florian Weimer writes:
 > * Andrew Haley:
 > 
 > > I'm sorry, but you're just being a bit too obscure for me.  What do
 > > you mean by "it tends to break"?  
 > 
 > vm.overcommit_memory=2 makes sure that the out-of-memory killer in the
 > kernel does not need to be run, by being extremely conservative about
 > handing out memory to applications.  Everything which is writeable needs
 > to be backed by its own chunk of RAM or swap space (unless it's a shared
 > mapping which is not copy-on-write, of course).  As a result, you run
 > into out-of-memory errors sooner, but they are much more predictable and
 > can usually be recovered from.
 > 
 > > If you could give an example to test, with a description of what you
 > > think should happen and what does happen, then I could talk to the
 > > kernel team.
 > 
 > The following instructions are for a machine that has got 4 GB of RAM
 > and 4 GB swap space.  You need to adjust the numbers accordingly if your
 > setup is different.
 > 
 > You need a simple Java application that runs indefinitely, for instance:
 > 
 > public class Wait {
 >     static public void main(String[] args) throws Exception {
 >         System.in.read();
 >     }
 > }
 > 
 > Now run
 > 
 > /usr/lib/jvm/java-6-sun/bin/java -XX:MaxPermSize=3g Wait
 > 
 > in three terminals.  The first two invocations will just wait for
 > input.  The third one will report this error:
 > 
 > Error occurred during initialization of VM
 > Could not reserve enough space for object heap
 > Could not create the Java virtual machine.
 > 
 > Because of vm.overcommit_memory=2, it does not matter how much of that 3
 > GB the application uses.  You can only create very few VMs if the
 > default heap size is a sizable chunk of your available RAM + swap.
 > 
 > How can this be fixed?  Hotspot uses this mmap call to allocate memory:
 > 
 > 11408 mmap(NULL, 4255186944, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2aaaaea31000
 > 
 > MAP_NORESERVE apparently doesn't do what it's name suggest (reserve some
 > address space, but do not commit to kernel to actually provide backing
 > store for it).

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:

       MAP_NORESERVE

              Do not reserve swap space for this mapping.  When swap
              space is reserved, one has the guarantee that it is
              possible to modify the mapping.  When swap space is not
              reserved one might get SIGSEGV upon a write if no
              physical memory is available.  See also the discussion
              of the file /proc/sys/vm/overcommit_memory in proc(5).

       /proc/sys/vm/overcommit_memory

              This file contains the kernel virtual memory accounting mode. Values are:
              0: heuristic overcommit (this is the default)
              1: always overcommit, never check
              2: always check, never overcommit
              In mode 0, calls of mmap(2) with MAP_NORESERVE set are
              not checked, and the default check is very weak, leading
              to the risk of getting a process "OOM- killed".  Under
              Linux 2.4 any non-zero value implies mode 1.  In mode 2
              (available since Linux 2.6), the total virtual address
              space on the system is limited to (SS + RAM*(r/100)),
              where SS is the size of the swap space, and RAM is the
              size of the physical memory, and r is the contents of
              the file /proc/sys/vm/overcommit_ratio.

This suggests to me that in Mode 2 the system is doing what it's
supposed to do.

Andrew.

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