>Unnamed anonymous mappings, by definition, are isolated at creation.  They have
>no reason for any copy-on-write status, nor any connections to any shadow
>objects.  Yet they acquire such status and connections, at some point after
>being created without them.  Wherever that happens, there can be no valid 
>reason for it, so there should be nothing to collapse.  It's a bug (whether 
>by design or otherwise) that generates useless duplicate pages.  The behavior 
>does not match the description of how the Mach vm is supposed to work 
>(in the CSRG book, for example).

anything that has "copy" inheritance will become copy-on-write at 
fork(2) time.  maybe that is what you are seeing?   it is hard to say
without seeing any debugging output.  [not that i want to spend a lot
of time digging into old BSD VM code...]


>I find the dumpster easy to understand.  My brain feels like spaghetti with
>meatballs and cheese.
>I do hope UVM is more efficient that this sucker.  I must say, though, I have
>yet to personally experience a "modern" OS that actually works right,
>especially with respect to vm.  (Of course, I'm cheap, so I've never laid out
>substantial bucks for any...)

well you can always try it and see.    

in the mean time, if you want to keep looking at Mach code, you should
also check out the FreeBSD stuff.  they have made a strong effort to
rescue the BSD/mach VM without deviating too much from the basic design.   
things are a bit clearer as they've thrown out copy objects, vm_pagers,  
and share maps.


>Right, but where does 'systat vmstat' get its other 3 pages?  (Come to think of
>it, if its numbers have everything double, that would explain a lot.)

sorry, let me restate.   of the 6 pages you are seeing, 3 show up
in the vm_map and 3 do not.

these pages are:
   
  - 3 PT (page table) pages: one to map the first 4MB of memory
	[for text+data], one to map the 4MB range around 0x40000000 
	where the shared libs get mapped in, and one to map the process'
	stack area (around 0xef800000).
  - 2 pages for the process' U-space (not in vm_map)
  - 1 page for the process' PDP (page directory page (not in vm_map))

the only reason you see those PT pages in the vm_map are because the
old i386 pmap keeps the user page tables in the top of the user's 
virtual address space.

chuck