[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