[LLVMdev] getting started with IR needing GC

[Gordon Henriksen]

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