Review request for 5049299 (original) (raw)

Christos Zoulas christos at zoulas.com
Tue May 26 16:23:47 UTC 2009

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

This is not a good solution because the vfork() semantics vary across different OS's (specially with respect to signal handling) and we probably need to come up with a simple test program to see if the particular vfork() implementation is suitable, or we have to fail back to using fork.

If there is a consensus to use vfork(): What is not clear to me is if java needs a special execute entry point that uses the fake or real vfork() (with the parent suspension semantics), or an implementation can just choose to implement execute using vfork() at it own digression.

christos

(*) On linux - for some earlier vintages that did not have a vfork() syscall - it is equivalent to calling clone(2) with flags CLONE_VFORK|CLONE_VM|SIGCHLD.

More information about the core-libs-dev mailing list