Review request for 5049299

[Christos Zoulas]

On May 26, 12:10pm, Michael.McMahon at Sun.COM (Michael McMahon) wrote:
-- Subject: Re: Review request for 5049299

| I played around with your test and I see similar behaviour on my Ubuntu 
| 8.04 system.
| When you switch on "always overcommit" (not the default) then you get 
| the expected
| behaviour, ie. you can go quite close to the VM limit, and manage to 
| spawn a small command
| from Java.
| 
| However, in the default "heuristic" mode, it doesn't work. The comment 
| on the web page
| you mentioned says:
| 
| "Heuristic overcommit handling. Obvious overcommits of
| address space are refused. Used for a typical system. It
| ensures a seriously wild allocation fails while allowing
| overcommit to reduce swap usage:
| 
| Perhaps, this specifically does not suit the Java VM situation where 
| fork() of a very
| large process, is considered an "obvious overcommit".
| 
| In that context, I'll look into using the clone() system call on Linux. 
| It seems
| to be quite versatile and configurable. It looks likely that we can 
| avoid the use
| of the helper command with it as well.

Let's forget about the overcommit heuristics/settings alltogether.
We need a portable solution to the problem that works in all scenarios.
In addition the jvm maps memory on linux with MAP_NORESERVED which makes
the situation even more complicated. Yes, overcommit is useful
in a typical workstation setup, but not in a server environment where
deterministic behavior is desired. 

christos