[LLVMdev] getting started with IR needing GC

[Lane Schwartz]

On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen
<gordonhenriksen at mac.com> wrote:
> On 2008-04-28, at 21:19, Lane Schwartz wrote:
>
>  > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com
>  > > wrote:
>  >
>  >>> If so, then a Collector plugin would need to have info about every
>  >>> supported backend lays out the runtime stack?
>  >>
>  >> Yes. This information is actually available in a target-independent
>  >> fashion with LLVM, so the Collector interface is target-
>  >> independent. A backend that doesn't use the target-independent back-
>  >> end could also implement support for values of gc "...", but this
>  >> is quite hypothetical.
>  >
>  > Right. So a GC plugin needs to know a few things in order to find GC
>  > roots. It needs to know the stack pointer, the frame pointer,
>  > possibly static links (if we allow nested functions), and where in
>  > the stack frame local variables live.
>  >
>  > How do you get access to this data in a platform-agnostic manner?
>
>  http://llvm.org/docs/GarbageCollection.html#stack-map

Good - I'd seen that earlier, but in this context it makes more sense.

>  >> Such a runtime will further need a way to crawl the native call
>  >> stack and discover the return address of each call frame. LLVM
>  >> doesn't provide such a facility.
>  >
>  > I guess I'm missing something here. Why does the GC need the return
>  > addresses?
>
>
>  Return addresses are directly discoverable from the stack; function
>  entry points are not.

If you have the stack, and can therefore determine all live GC roots,
why do you need function entry points? Is it so you know *when* you
can safely run garbage collection?

Sorry if I'm a bit dense on this point. I thought I'd read up on the
topic, but obviously I missed something here.

Thanks for your patience,
Lane