Review request for 5049299

[Christos Zoulas]

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 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?
| 

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.