GC triggering and stack limit checking by MMU hardware

[Guy Harris]

(UNIX issue, not system architecture issue, at this point)

>>Rather than mapping a file, you can map /dev/zero, which provides zero
>>filled copy on write pages.

No, it provides zero-fill on demand pages; there's no copy-on-write
involved, and no copy-on-write needed.  (It provides the same kind of
pages as the kind that lie behind BSS space when an executable image is
run, behind pages added on with "sbrk()", and behind pages added on to
swap space.)

>Ever hear of anonymous mapped memory.

Yes, it's what you get when you "mmap()" "/dev/zero" in SunOS 4.x and
System V Release 4.

>Check out the 4.3BSD Architecture Manual (PS1:6) for a description of
>this rarely (or almost never) implemented feature.

Yup.  That section says that the "flags" field of the "mmap()" call
has one of two mapping types, MAP_FILE and MAP_ANON, defined as 0x0001
and 0x0002 in <sys/mman.h>, and one of two sharing types, MAP_SHARED and
MAP_PRIVATE, defined as 0x0010 and 0x0000 in <sys/mman.h>.

Of course, the <sys/mman.h> that actually *came* with 4.3BSD and
4.3-tahoe has, instead,

	/* sharing types: choose either SHARED or PRIVATE */
	#define	MAP_SHARED	1		/* share changes */
	#define	MAP_PRIVATE	2		/* changes are private */

which would seem to conflict with MAP_FILE and MAP_ANON, and doesn't
have MAP_FILE or MAP_ANON themselves.

So Sun, I guess, is guilty of modeling "mmap()" more after what 4.3BSD
actually appears to have intended to do, based on the code, rather than
what the 4.3BSD Architecture Manual claimed they intended to do.  Then
again, often, when confronted with UNIX, you have to go with what the
code says, not what the documentation says; Berkeley may simply have
changed their mind and forgotten to update the Architecture Manual....

>Using MAP_ANON causes the memory to be zero filled, but not 
>necessarily copy on write.

Yup, just like mapping "/dev/zero".