Xref: utzoo comp.arch:17227 comp.lang.functional:297 comp.lang.lisp:3419 comp.lang.prolog:2951
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ncar!boulder!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: comp.arch,comp.lang.functional,comp.lang.lisp,comp.lang.prolog
Subject: Re: GC triggering and stack limit checking by MMU hardware
Message-ID: <23674@boulder.Colorado.EDU>
Date: 19 Jul 90 17:50:49 GMT
References: <1990Jul19.151524.22544@diku.dk>
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Organization: University of Colorado at Boulder
Lines: 34
In-reply-to: torbenm@diku.dk's message of 19 Jul 90 15:15:24 GMT


T> Assign to each stack/heap an event that is invoked by the MMU trap
T> handler on access to unmapped memory. An event can ask for a new
T> physical page to be mapped to the corresponding area, or maybe try to
T> do garbage collection.
T> 
T> Virtual memory can handle the stack problem, as the only sensible
T> thing to do would be to assign new pages. However, triggering garbage
T> collection in the way described above is different from just extending
T> the virtual memory space. Furthermore, the idea is perfectly usable
T> even on systems with no virtual memory 
	...
T> 
T> My question is: has this been done? And if not, why not?
	...
T> 	Torben Mogensen (torbenm@diku.dk)
--

Yes, see work by Andrew Appel on just this notion. I know it came out
as DEC-SRC tech report, and was published elsewhere as well. I think
he advocated this for the SML system.

You can do something similar to this in Ultrix and SunOS using the
``mprotect'' call to protect specific pages of memory, and then use a
signal handler for faults/seg violations (whatever error is normally
raised).

I've done this to protect the stack segments for my tasking library;
when creating 1000's of tasks, it's a little wasteful of time and
space (like, 2x slower and 4x larger when using 8K pages), but it
certainly helps locate tasking bugs.

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)
						(grunwald@boulder.colorado.edu)