Re: Controlling the garbage collector (GC) at RT?

[Chris Gray <chris dot gray at kiffer dot be>]

On Thursday 10 February 2005 02:19, Boehm, Hans wrote:
> It would indeed be interesting to know why the Linux kernel kills
> the application rather than returning failure.

According to 'man malloc' on a linux box (Debian 3.1):
	
BUGS
       By default, Linux follows an  optimistic  memory  allocation  strategy.
       This  means  that  when malloc() returns non-NULL there is no guarantee
       that the memory really is available. This is a really bad bug.  In case
       it  turns  out  that the system is out of memory, one or more processes
       will be killed by the infamous OOM killer.  In case Linux  is  employed
       under  circumstances  where it would be less desirable to suddenly lose
       some randomly picked processes, and moreover the kernel version is suf-
       ficiently recent, one can switch off this overcommitting behavior using
       a command like
              # echo 2 > /proc/sys/vm/overcommit_memory
       See also  the  kernel  Documentation  directory,  files  vm/overcommit-
       accounting and sysctl/vm.txt.

The man page is dated 1993-04-04, but I have also seen man pages dated "April 
4, 1993" which have a completely different text. So it's not easy to 
determine what kernel/glibc version is required - experiment and see.

This behaviour has cause unbounded aggravation in the past, with user 
complaining that "[insert your VM here] just quits without any message. On 
JDK it works fine", blah blah blah. It would be worth patching in embedded 
Linux distributions.

Foo,

Chris