On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote:> As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the llvm_cg_walk_gcroots routine from the semispace example. Call it > from your collection routine in order to visit each gcroot on the > runtime stack. > > The shadow stack lets you find roots by automatically emitting a > function prologue and an epilogue to push and pop gcroot entries on a > stack as the program runs. This avoids the need to traverse the native > call stack. If your language becomes sufficiently performance > sensitive, you can later investigate implementing a custom Collector > plugin.OK. This is helpful in trying to understand what the Collector plugin is. So is it correct then that the Collector plugin is the GC's view into the backend? In other words, most garbage collectors have to have some knowledge of how the runtime stack is actually laid out. ShadowStack skirts around this issue by maintaining a "shadow" stack, so when the GC needs info about the runtime stack, ShadowStack instead provides info about the "shadow" stack. But most collector plugins would instead have to know about the actual layout of the runtime stack. Is that right? If so, then a Collector plugin would need to have info about every supported backend lays out the runtime stack? Thanks, Lane
On Apr 28, 2008, at 14:28, Lane Schwartz wrote:> On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen > <gordonhenriksen at mac.com> wrote: > >> As for the compiler plugin interface, I suggest you ignore it >> initially and use the provided shadow-stack option for the time >> being. The shadow stack generates significantly suboptimal code, >> but will let you avoid writing some platform-specific code. >> Instead, simply copy the llvm_cg_walk_gcroots routine from the >> semispace example. Call it from your collection routine in order to >> visit each gcroot on the runtime stack. >> >> The shadow stack lets you find roots by automatically emitting a >> function prologue and an epilogue to push and pop gcroot entries on >> a stack as the program runs. This avoids the need to traverse the >> native call stack. If your language becomes sufficiently >> performance sensitive, you can later investigate implementing a >> custom Collector plugin. > > OK. This is helpful in trying to understand what the Collector > plugin is. > > So is it correct then that the Collector plugin is the GC's view > into the backend? In other words, most garbage collectors have to > have some knowledge of how the runtime stack is actually laid out. > ShadowStack skirts around this issue by maintaining a "shadow" > stack, so when the GC needs info about the runtime stack, > ShadowStack instead provides info about the "shadow" stack. But most > collector plugins would instead have to know about the actual layout > of the runtime stack. Is that right?That's correct.> 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. 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. — Gordon
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