Controlling the garbage collector (GC) at RT?

Fri Feb 11 02:15:00 GMT 2005

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