Xref: utzoo comp.arch:17279 comp.lang.functional:313 comp.lang.lisp:3435 comp.lang.prolog:2972
Path: utzoo!utgpu!watserv1!watmath!att!bellcore!messy!mo
From: mo@messy.bellcore.com (Michael O'Dell)
Newsgroups: comp.arch,comp.lang.functional,comp.lang.lisp,comp.lang.prolog
Subject: Re: GC triggering and stack limit checking by MMU hardware
Keywords: GC, stack, heap, MMU
Message-ID: <25580@bellcore.bellcore.com>
Date: 21 Jul 90 23:14:46 GMT
References: <1990Jul19.151524.22544@diku.dk>
Sender: news@bellcore.bellcore.com
Reply-To: mo@messy.UUCP (Michael O'Dell)
Organization: Center for Chaotic Repeatabilty
Lines: 20

Interlisp did this as a matter of course, and Vax-Interlisp was
the single biggest reason for the originally-published
(as opposed to originally discussed but not published)
4.2BSD virtual memory proposal being page-based, just like Tenex.
This was finally implemented in Mach and SunOS 4.0, and
is forthcoming in 4.4BSD.

While this sounds like a good idea, it may not be on very fast
computers.  Providing user programs with completely general
program state access on segmentation faults can be VERY expensive.
I worked on one design whereby the kernel could do all the
usual stuff (copy-on-write, etc) by "reeffecting" faulting instructions
even in the face of out-of-order instruction completion,  But 
letting the user program poke its nose around as described by the
signal() interface requires "atomic trap behavior", and
that makes a program run MUCH MUCH slower on some machines.
For details, see my paper "Putting UNIX on Fast Computers"
in the latest USENIX Anaheim Conference Proceedings.

	-Mike