[LLVMdev] Garbage collection questions

[Sandro Magi]

On 2/27/06, Chris Lattner <sabre at nondot.org> wrote:
> > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr)
> >
> > I haven't seen an adequate explanation of these, but I'm guessing:
> >  void *V: value being written to the field
> >  void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr
> > upon entry to llvm_gc_write)
> >  void **FieldPtr: address of the field being written
>
> Close: ObjPtr is designed to be a pointer to the head of an object.  For
> example, to codegen:
>
> Obj->Field = Ptr;
>
> you'd want to compile it as:
>
> llvm_gc_write(Ptr, Obj, &Obj->Field);
>
> This is used by the GC if it keeps bits in the object header or other
> things.  If the GC you plan to use doesn't need this info, you don't need
> to provide it obviously. :)

Makes sense. A few more questions:

1. Any generic LLVM GC must be customised for a given front-end,
correct? In other words, it requires front-end information regarding
the layout of pointers within a block in order to fully trace the
reference graph. Or am I missing something? Is semispace a drop-in for
any front-end that utilizes the llvm.gc* intrinsics?

  1a. Semispace isn't actually complete/working is it? Its
llvm_gc_collect() implementation doesn't actually seem to do anything,
ie. no copying, no space switching, etc. :-)

2. Are there any GC tests available that I can use to test a GC implementation?

3. The description for llvm.gcroot
(http://llvm.cs.uiuc.edu/docs/GarbageCollection.html#roots) indicates
it's used to identify roots on the stack. A front-end can also use it
to identify global static data can it not?

Sandro