Review request for 5049299

[Martin Buchholz]

On Sat, May 23, 2009 at 01:28, Andrew Haley <aph at redhat.com> wrote:

> Martin Buchholz wrote:
> > On Fri, May 22, 2009 at 15:13, Michael McMahon <Michael.McMahon at sun.com
> >wrote:
> >
> >> Martin,
> >>
> >> Thanks. Great comments. Just a few comments of my own
> >> on a couple of points.
> >>
> >> 1. Linux won't benefit from this change as much as solaris, since due to
> >> its
> >>   "memory overcommit" architecture, it doesn't suffer from the problem
> (so
> >> much)
> >>    in the first place (though memory overcommit causes some problems of
> its
> >> own).
> >>    Nevertheless, maybe it could simplify the code a bit if we use
> >> posix_spawn() on Linux
> >>    as well. So, I will look into that.
> >
> > Any company running server farms (think "Sun" or "Google")
> > would like to "bin-pack" as many processes as possible onto them,
> > and transient doubling of process size is a big problem in such an
> > environment.  Think of this as a
> > saving-the-planet-from-global-warning feature.
>
> But those running Linux won't benefit from such a change because
> on Linux there is no transient doubling of process size: all that happens
> is that the page table entries in the new process are mapped copy on write.
> The extra pages count towards the overcommit limit, but that's wholly
> artifical.
>

I confess to incomplete understanding of the situation on Linux, but...
I agree that the limit is artificial,
in that there is no doubling of actual  memory.
It's a monitoring problem, whether internal to the linux kernel
or perhaps some other external software "accounting" entity.
Nevertheless, I believe this limit prevents a process currently using
75% of memory from starting a small subprocess and
expect that clone() with CLONE_VM will fix that.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090523/bd22dd4f/attachment.html>