UI demo performance, GC

[Timmy Douglas]

Brian Rice <water at tunes.org> writes:

> On Mar 20, 2007, at 7:56 PM, Timmy Douglas wrote:
>> Brian Rice <water at tunes.org> writes:
>>
>>> Note that it uses Squeak-style forwarding pointers which is not
>>> the same as Lee's choice of card-marking as a scheme for
>>> GC. Card-marking does have its advantages (which can be found with
>>> a little research).  Mostly I wrote it as an exercise in comparing
>>> Pidgin vs. Slang, the C- like dialects for VM implementation.
>>
>> When you say card-marking, are you referring to the kind with
>> write-barriers that maintain a list of old generation -> new
>> generation mappings? It seems that the cards in mark-compact.slate
>> just make sure that stuff on the C stack isn't moved during the
>> garbage collection.
>
> Yes, there is at least a slight difference between what Lee
> implemented and the term card-marking, although they relate. Lee
> didn't prioritize generational GC support.

ok

>> 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.


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)


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?