Review request for 5049299 (original) (raw)

Christos Zoulas christos at zoulas.com
Tue May 26 12:57:43 UTC 2009

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

More information about the core-libs-dev mailing list