[LLVMdev] Why LLVM should NOT have garbage collection intrinsics

[Gordon Henriksen]

On Feb 27, 2009, at 12:56, Mark Shannon wrote:

> Gordon Henriksen wrote:
>
>> 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.
>
> Elimination of the reload penalty is impossible, unless the GC can  
> be informed about traceable objects in registers.

Exactly.

>> 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.
>
> No collector plugins actually use gcread/gcwrite, since there  are  
> no generational collectors for llvm (as yet).
>
> According to the documentation
> http://llvm.org/docs/GarbageCollection.html#runtime
> The GC interface is "a work in progress"

The "runtime interface" is a historical artifact. LLVM does not impose  
a runtime library on its users. I wouldn't have a problem deleting all  
mention of it, since LLVM does not impose a contract on the runtime.

> The semantics of llvm.gcroot are vague:
> "At compile-time, the code generator generates information to allow  
> the
> runtime to find the pointer at GC safe points."
>
> Vague, ill-specified interfaces are worse than none.

There's nothing ill-defined about the semantics of gcroot except  
insofar as GC code generation is pluggable.

> Fundamentally, implementers of new back-ends shouldn't have to worry  
> about GC, and implementers of GC algorithms should not have to delve  
> into the internals of the back-end.


This is precisely the current state of affairs.

— Gordon