[LLVMdev] getting started with IR needing GC
dowobeha at gmail.com
Mon Apr 28 19:39:18 PDT 2008
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?
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,
More information about the llvm-dev