[LLVMdev] Garbage Collection Roots

[Talin]

On Sep 2, 2007 5:31 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote:
> Hi Talin,
>
> On Sep 2, 2007, at 04:54, Talin wrote:
>
> > I've been looking through the documentation (http://llvm.org/docs/
> > GarbageCollection.html) on how to implement a garbage collector for
> > LLVM and there's a couple of things that I don't quite understand.
> > Specifically, it says that when a stack variable goes out of scope,
> > you're supposed to assign a null value to it to indicate that the
> > value is no longer live.
> >
> > What I don't quite understand is how the GC can efficiently use
> > this information.
>
> The GC intrinsics exist for the type of collector which depends on
> metadata compiled alongside the function. At runtime, such a
> collector walks the dynamic call stack and merges that with the
> static metadata to identify dynamically live roots. Like "zero cost
> exception handling" or debug info, collecting this kind of metadata
> requires backend code generator support, which again is the reason
> these intrinsics exist.

So, if I understand what you are saying correctly, the "llvm.gcroot"
intrinsic isn't actually an "instruction" in the sense I normally
think of as an action to be taken; It's more of a marker which is used
by the code generator to create a data structure that describes the
stack layout. Is that correct?

If that's the case, then my next question is: How do the LLVM garbage
collection intrinsics work in a multi-threaded environment? If there's
a data structure that describes the layout of the stack, and you have
multiple stacks, what happens?

BTW, I'm also noticing that the current SemiSpace example code seems
quite incomplete.

-- 
-- Talin