I've always wanted to see incremental gc based on the train algorithm put into the Self system.

http://www.daimi.au.dk/~beta/Papers/Train/train.abstract.html http://www.daimi.au.dk/~jacobse/Papers/dOOVM/train-doovm.ppt

-greg

On Tuesday, August 27, 2002, at 06:12 PM, Jecel Assumpcao Jr wrote:

On Tuesday 27 August 2002 18:29, Steve Dekorte wrote: I think I remember reading that Self uses a generational copying garbage collector. Is that right?

Yes, there is a "eden space" where new objects are born, two areas forming semi-spaces for "young objects" and a large area of old objects. So we have three generations in all.

If so, I'm curious about why that approach was taken instead of something like an incremental tri-color collector.

Probably one of the language's designers read this paper and thought it was a good idea:

David Ungar, "Generation Scavenging: A Non-disruptive High Performance Storage Reclamation Algorithm", in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, 1984.

;-)

A generational collector would avoid the frequent pauses of a mark and sweep collector but would still have infrequent pauses which (I would think) would be a problem for a interactive system.

It is indeed a problem - I have spent quite a while staring at the "collecting garbage" dialog box waiting for the system to unfreeze. But that is simply because no effort was made to make the "old space" collection more incremental. If such an effort/redesign were made (while keeping the other generations as they are now) then the system would be more suitable for interactive use.

-- Jecel

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/