Xref: utzoo comp.arch:17272 comp.lang.functional:312 comp.lang.lisp:3433 comp.lang.prolog:2970
Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!pereira
From: pereira@alice.UUCP (Fernando Pereira)
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: <11075@alice.UUCP>
Date: 20 Jul 90 19:51:13 GMT
References: <1990Jul19.151524.22544@diku.dk>
Reply-To: pereira@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 46

In article <1990Jul19.151524.22544@diku.dk> torbenm@diku.dk (Torben [gidius Mogensen) writes:
>
>By using the MMU facilities present in most modern computers, these
>tests can be entirely done in hardware, and fragmented stacks can be
>done transparently. This is the idea:
>
>Give each stack or heap a small number of pages of memory and make
>sure that the logical addresses are far apart, and that a large
>logical address space is given each, but where only the first small
>part is actually mapped to physical (or virtual) memory.
>
>Assign to each stack/heap an event that is invoked by the MMU trap
>handler on access to unmapped memory. An event can ask for a new
>physical page to be mapped to the corresponding area, or maybe try to
>do garbage collection.
> [...]
>My question is: has this been done? And if not, why not?
>
>I suspect that operating systems like Unix doesn't provide such
>facilities to user processes, but the issue is then: should they?
>

I know of Prolog and ML implementers that have tried this, but unfortunately
it is not a portable solution in Unix, even those versions that offer the
mmap system call to create ``islands'' of virtual address space. The problem
is that certain machine architectures (eg. Motorola 68K) and OS
implementations (eg. SunOS at least in some versions) do not provide
a continuable address violation signal (SIGSEGV), even though at the kernel
level, address translation faults (page faults) are continuable. Not having
looked at the insides of those machine/OS combinations, I suspect that
enough instruction execution context can be saved for filling a page fault
in the kernel, but not enough for reentering the faulting process to
handle a Unix signal and allocate the needed storage.

These observations are the result of practical experiments 5 or so years
ago with Sun 2's and VAXen running Berkeley Unix. The former could not
recover correctly from the segmentation violation (PC corrupted on return
from the signal), the latter could. Newer machines/architectures might handle
this better, although comments I have heard from the SML-NJ implementers
indicate that there are problem configurations even now.

Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, Murray Hill, NJ 07974
pereira@research.att.com