[LispM-Hackers] Outageness

[John Morrison]

Hi;

Paul Fuqua wrote:
> 
>     Date: Tue, 26 Feb 2002 17:48:22 -0500
>     From: jm@mak.com
> 
>     Can you please either elaborate or point me at a section of any
>     available documentation?
> 
> I figure that paging doesn't really have to be emulated in great
> detail.  I mean, we get a virtual address and go find it in the band or
> swap space, and don't have to worry about page faults or disk
> operations.

I think I understand you, and, if I do, I agree with you.

> On the other hand, GC takes place partly in Lisp, partly in microcode
> ops, and partly deep in the microcode -- there's a GC process that hangs
> around to do some scavenging and space-flipping, and both it and the
> scheduler use %gc-scavenge, and TGC depends on read and/or write
> barriers that happen around main-memory accesses.
> 
> As a first cut, we can just ignore GC, which would be equivalent to
> having GC turned off in a running Explorer.  But what's the right way to

This is my understanding of the current plan.  Ditto for paing.

Even later, we should just tell people to go buy more memory! 
www.pricewatch.com says PC100 64MB costs $5 now.  We only need on the
order of 128MB, right?  $10 worth of memory?  I think that's not a bad
deal.

(Remember back when 128MB was an unimaginably vast ocean of memory?)

> go from there?  I've idly speculated about having a conventional GC
> running behind the scenes, or emulating enough of the background
> microcode to get by, or just doing stop-and-copy, but mostly I just
> ignore the problem and hope it goes away.

I know this sounds weird, but the JavaOS clone stuff has a conservative
garbage collector in it.  It seemed to work, too (although obviously the
tag bit stuff will interfere...)...

> Chapter 10 of the SSDN talks about GC.  It lists the subprimitives it
> uses, which are the various microcode entry points from Lisp.

Thanks!

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com