Info Dylan Digest V1 #147 
Author Message
 Info Dylan Digest V1 #147

> Date: Sat, 30 Oct 93 16:49:25 -0700

> ....
> Furthermore, ephemeral GC and generation-counting GC are not
> necessarily the same thing, at least not in the sense of ephemeral GC
> as developed by David Moon at Symbolics. He wrote a paper on it that
> was presented to an ACM conference back in the 80s that is very
> illuminating, by the way, and provides a lot of food for thought about
> implementation issues. So far I have not encountered "moon-style"
> ephemeral GC on anything but a Symbolics, which doesn't mean it hasn't
> been done, of course. However, out of curiousity, I checked with some
> ex-Symbolics people from the above-mentioned Western Engineering
> Division and their experience was the same. Any comments, Mr Moon?

No big comments, since I don't know what exactly you mean by "Moon-style".  
Since I haven't written a GC for any shipping product except the Symbolics
machines, and my brother does IC chip process design, not software, by
definition there are no "Moon-style" GCs on other platforms.

Hardware support speeds up garbage collection, but only by a constant factor
so it's not an essential thing to have, just nice when it's cost-effective.  I
don't know the numerical value of the factor, it's probably something like 2
or 3, not huge.  Many people get hardware support for garbage collection from
the memory address translation hardware, although the benefit is dubious
because the granularity is way too large and often the operating system does
its best to get in your way.  Very few people now enjoy hardware support for
type filtering, as seen on the Symbolics and TI Lisp machines.

My ephemeral GC was also incremental (i.e. the application program was
not stopped for the entire duration of the GC, instead it was stopped
and started in several little bursts), and had support in the virtual
memory system to avoid excessive disk I/O.  In fact most garbage collections
did no disk I/O at all, if I remember the measurements correctly.  Those two
features aren't usually found in other ephemeral GCs that exist now, although
I think some of those GCs are still quite reasonable.

Of course, as we should all know by now, virtual memory is a bad idea anyway,
especially in the kind of interactive graphics systems you're talking about.  
In the absence of virtual memory, incremental GC is less important since the
total GC time is smaller and more predictable.  Fortunately, the Dylan
language does not require virtual memory (nor does it forbid virtual memory)
(this is a Dylan mailing list, right?  It's hard to tell sometimes!).

Sat, 20 Apr 1996 09:20:37 GMT  
 [ 1 post ] 

 Relevant Pages 

1. INFO-ADA Digest - 29 Jun 1998 (#1998-147)

2. Info Dylan Digest Digest V1 #127

3. Info Dylan Digest Digest V1 #114

4. Info Dylan Digest Digest V1 #122

5. Info Dylan Digest Digest V1 #84

6. info-dylan-digest V1 #24

7. Info Dylan Digest V1 #191

8. Info Dylan Digest V1 #177

9. Info Dylan Digest V1 #149

10. Scheme Digest #147

11. Info Dylan Digest V2 #43

12. Info Dylan digest V2 #682


Powered by phpBB® Forum Software