[LLVMdev] Why LLVM should NOT have garbage collection intrinsics[MESSAGE NOT SCANNED]

[Gordon Henriksen]

Hi Mark,

I don't think anyone will dispute that it's easier to hack up a shadow  
stack (or plug into a conservative collector) to get up and running  
with GC. That is absolutely the route to go if portability trumps  
performance.

If you review the mailing list history, I think you'll also find that  
developers who do care about performance have been disappointed with  
the impact of using a shadow stack, either managed with LLVM  
intrinsics or by hand. Even the current state of LLVM GC (static stack  
maps) is a significant performance improvement—but it absolutely does  
require support from the code generator. Return addresses must be  
mapped to stack maps, and only the code generator knows where return  
addresses lie and how the stack frame is laid out.

The ultimate endgoal is to support schemes with still-lower execution  
overhead. The next step for LLVM GC would be elimination of the reload  
penalty for using GC intrinsics with a copying collector. This, again,  
requires that the code generator perform bookkeeping for GC pointers.

On Feb 27, 2009, at 06:38, Mark Shannon wrote:

> If I want to use the llvm.gcwrite intrinsic for my write barrier  
> then I need to write a GC and then implement for each and *every*  
> backend the gcwrite intrinsic for my write barrier.

I'm not sure where such vociferous concern on this subject arises. All  
the extant collector plugins I'm aware of operate in conjunction with  
the target-independent framework and require exactly zero code within  
each target backend.

— Gordon