| > I don't actually see why there is a gain from using mmap() directly
| > for malloc()?
|
| Well, there isn't any, per se.  The gain actually comes from
| eliminating sbrk (and brk) entirely; making malloc use mmap is related
| only because that's the only place anyone has come up with for malloc
| to get new memory if sbrk vanishes.
|
| The gain I refer to is mostly that there is no need to maintain a
| max-data-segment-size VM hole between the current break and the lowest
| place the system may put an mmapped segment.  (Okay, the hole size is
| actually max data segment size minus current data segment size.)  On
| machines with single-level page tables (like the VAX), maintaining that
| hole is a pain.
|
| By moving things around in VM, it's possible to shrink the hole to the
| maximum stack size, which is usually less than the maximum data size.
| But by removing sbrk/brk entirely, it's possible to eliminate it
| altogether.

I don't think that's at all correct.  If you ever use sbrk(), whether
in the kernel or emulated, it needs to extend the data segment, or
you lose its semantics.  Since we use dynamic libraries, and the 
dynamic linker uses mmap() without MAP_FIXED, those mappings need to
be somewhere where they will not conflict with possible emulated
sbrk() calls.

Now malloc() can be made intelligent and use MAP_FIXED to allocate
out of the sbrk() area, but that's pretty much the same situation we
have now.  So, getting rid of sbrk() will not fix the vax pmap
problem unless you use a broken sbrk() implementation or get rid
of sbrk() entirely.

So what do we really gain by changing malloc() to use mmap() 
instead of sbrk()?  Nothing.

Well, I suppose that's not entirely true.  With enough work
we might be able to get malloc() to destroy address space when
there's enough contiguous free space to unmap.  But that's 
unlikely to be very effective due to fragmentation unless we
change the malloc() interface itself.  (That's one of the 
primary reasons for pool(9).)

Eduardo