UI demo performance, GC

[Brian Rice]

On Apr 7, 2007, at 12:32 PM, Timmy Douglas wrote:

> Brian Rice <water at tunes.org> writes:
>> On Mar 20, 2007, at 7:56 PM, Timmy Douglas wrote:
>>> How many changes would gc.slate have to undergo to be functional? It
>>> looks fairly complete but I can't really understand how it works
>>> without spending a few hours on it.
>>
>> I don't know. I performed a fairly literal translation on a working
>> piece of code, but Slate's memory layout is somewhat different and we
>> never compiled with that GC.
>
> Yeah, I've had some time to look around Squeak's GC/ObjectMemory and
> compare it to some of the stuff in slate. Below I'm going to try to
> think out loud on how some features work, so make any comments if I'm
> missing something.
>
> Basically I think Squeak's GC has these features:
>
>   1. Recursively marking the interpreter stack/special objects only if
>   they are young (but in a full GC the young start is moved to
>   startOfMemory so everything is considered young)
>
>   2. Recursively marking the root table (in Squeak this is *only* a
>   table with old generation objects with pointers to young objects)
>   which is updated on pointer accesses (possibleRootStoreInto)
>
>   3. The sweep phase goes through all objects as if they were a linked
>   list from youngStart (which is startOfMemory in a fullGC). The
>   sweep phase also unmarks objects as it sees them.

That's a simplified overview, yes.

> The Slate mark-compact.slate GC:
>
>   1. Every object that is traced is an object on RootStack or
>   connected to one on the stack. Some primitive methods call
>   rootStackPush if they make an object that needs to be kept.
>
>   2. It pins stuff that is pointed to by the C stack so it isn't
>   compacted. (versus forwarding pointers in squeak? I haven't spent
>   too much time figuring out compaction)

That's correct.

> I like that the code executed for a Squeak GC is almost the same
> whether it's an incremental GC or full GC (basically just the
> youngStart pointer changes). I think it might be easier to extend
> mark-compact.slate to use generations rather than modifying squeak's
> gc to work for slate. I guess in order to do that we'd have to:
>
>   1. Add a youngStart variable and adapt the marking so that only
>   things are marked if they are past this location. (Except I'd rather
>   add a gcStart variable or something which is set to either
>   youngStart or startOfMemory)
>
>   2. We need a table like the old->young pointer table in squeak where
>   we have a list of all objects that point to young objects. The
>   incremental gc will scan the mark-compact root table and this table
>   to mark all the young objects. Then we have to start at youngStart
>   when we sweep/compact. That leaves the question: what functions need
>   to call this possibleRootStoreInto function? I'd have to modify
>   slot accessor functions and stuff outside of mark-compat.slate.
>
> I guess it's more complicated than that but that's my understanding of
> the problem right now. What do you think?

I'm not sure what to advise at this point. I've got my attention on a  
lot of different projects these days and not much in Slate.

A vaguely relevant email found via Googling:
http://bespin.org/pipermail/slate/2005-January/001032.html

I've decided to put enough effort into Slate that random interested  
people can try it out and contribute. I'll detail what I do in a  
separate email thread.

--
-Brian
http://briantrice.com