[LLVMdev] getting started with IR needing GC
gordonhenriksen at mac.com
Mon Apr 28 12:13:36 PDT 2008
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?
> 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
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.
More information about the llvm-dev