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?> 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? Thanks, Lane
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>> 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. — Gordon
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-mapGood - 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