Review request for 5049299

[Michael McMahon]

Christos Zoulas wrote:
> 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,

Can you elaborate on what you have in mind?

Michael.