Chuck Cranor said:
> 
> right, but there are a lot of malloc(3)'s out there that don't bother 
> to munmap or sbrk(-) the heap (so that memory never actually gets freed
> by the process, let alone the kernel).
> 
> as you point out, the vm_map_clip_start/vm_map_clip_end is going to
> muck with the object reference counts.
> 
My fix on FreeBSD is only a work around, and I'll have a rather complete
fix ready from my queue today or tomorrow.  The fix should be fairly
applicable to the original VM code+ (NetBSD,OpenBSD) and the
FreeBSD Mach VM code.

The key to the fix (which I have actually had available in my personal
kernels for quite a while), is to know when an object's pages (as
opposed to mappings) can be removed.  Your comments about object
reference counts are true, and the effect cascades, to the point
where it is apparent that such reference counts are not applicable
for using them as indicators of the appropriateness of removing
pages for memory and swap.  It is possible that it is reasonable
to do what I have (not committed yet) on FreeBSD now (I haven't
messed with the original MACH code in detail for awhile, other
than to do some proprietary NCI modifications), but I really do
think that the original Mach VM code could do what I plan.

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.