Review request for 5049299 (original) (raw)

Michael McMahon Michael.McMahon at Sun.COM
Tue May 26 16:39:22 UTC 2009

Christos Zoulas wrote:

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

| Christos Zoulas wrote: | > 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? | I don't have a good solution. The only option I see to to use vfork(2) on systems that have it (*), and emulate it by suspending the parent manually on systems that don't in order to achieve the same process scheduling semantics. This of course takes away all the vfork() benefits (speed/efficiency, avoiding the memory exhaustion issues). Unfortunately, vfork() on Solaris, won't do what we want to do. vfork() cannot be used in multi-threaded apps, on Solaris.

So, I think we are stuck with different solutions for Solaris and Linux. While it's not an ideal situation, at least it means we can still have consistent behaviour across both operating systems.

More information about the core-libs-dev mailing list