Review request for 5049299 (original) (raw)

Michael McMahon Michael.McMahon at Sun.COM
Tue May 26 14:20:08 UTC 2009

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 MAPNORESERVED 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.

More information about the core-libs-dev mailing list