[LLVMdev] Garbage collection questions

Chris Lattner sabre at nondot.org
Tue Mar 14 11:48:28 PST 2006


On Mon, 27 Feb 2006, Sandro Magi wrote:
> 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?

Correct.  The GC implementation and the front-end need to communicate 
through some descriptors that they can choose to define in any way they 
like.

> Is semispace a drop-in for
> any front-end that utilizes the llvm.gc* intrinsics?

I don't understand.

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

Yup, it's not done. :(

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

No, not really.

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

This is like the first question: the GC impl and the front-end need to 
communicate to each other where the globals are and their types, but LLVM 
doesn't specify how this happens.

One way to think about what LLVM provides: it provides the ability to walk 
the stack, accurately collecting GC heap references out of the stack 
frames.  These references can optionally be associated with metadata.

It's up to the front-end and runtime (GC impl) to decide how to use this 
basic support to communicate most effectively.  Note that if, for example, 
a conservative collector is enough, you can just strap one to LLVM without 
using this functionality at all. :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/




More information about the llvm-dev mailing list