Just to correct a few minor (possible) misunderstandings:

> > This is the well-known "swap-leak" bug. What happens is that swap
> > space allocated to a VM object is never deallocated until the VM
> > object is destroyed. Thus, when part of a daemon is paged out, and
> > paged back in again, the swap space allocated remains allocated to
> > that daemon, even though that daemon doesn't need it after being paged=
> 
> > back in. Since daemons don't exit at all, the swap space is never
> > reclaimed. (actually, the swap space can be reclaimed by going to
> > single user mode - you should notice used swap space going back to 0
> > after a "shutdown now").

Well, that's what is happening in (nearly?) all OSs (at least all the
ones I know of).  Swap space allocated to anything (independently of the
VM organization in objects, vm spaces or what else) is only reclaimed when
this "anything" gets destroyed.

> Actually, there's another leak in there; shadow objects are never reclaimed,
> ever.  Luckily, shadow objects aren't created very often unless you have many
> programs, descendents of each other, modifying the same mmap()ed file, but you
> may see a slow, steady leakage of VM due to this on, say, news servers.

This isn't completely correct.  Shadow objects are reclaimed under light load.
Only if shadow objects have had swap space allocated (which happens when the
first page of the object has to be paged out) does it stay in the shadow chain
until the shadowing object ist destroyed.

The typical cause for long permanent shadow chains is a daemon that forks
and modifies data that get paged out before the children can do exec or exit.

> This is all modulo someone explaining the "shadow object leak" to me a long
> time ago before I had even the slightest idea how the VM system worked, my
> subsequently acquiring the slightest idea thereof, and a quick look at the
> code just now.  If I've munged up some part of the explanation or someone more
> qualified would like to explain it better I'd love to benefit from that.

Hope I've done that above :-)
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800