[LLVMdev] Future plans for GC in LLVM

[Philip Reames]

On 01/25/2015 06:56 AM, Manuel Jacob wrote:
> Hi,
>
> On 2014-12-05 02:50, Philip Reames wrote:
>> Questions:
>> - Is proving the ability to generate a custom binary stack map format
>> a valuable feature?  Adapting the new statepoint infrastructure to
>> work with the existing GCMetadataPrinter classes wouldn't be
>> particularly hard.
>
> I think custom binary stack map formats are valuable (smaller and 
> easier to parse).  I'm also willing to implement this after the code 
> around GCStrategy is a bit more stable.
Great to hear.
>
>> - Are there any GCs out there that need gcroot's single stack slot per
>> value implementation?   By default, statepoints may generate a
>> different stackmap for every safepoint in a function.
>
> Probably not, since the GC runtime looks only at one safepoint per 
> stack frame and doesn't care about the other safepoints in the 
> function.  For saving space it's probably a better idea to have a 
> custom stack map format with some form of compression (e.g. a bitmap).
The default lowering for gc.root definitely supports multiple safepoints 
per frame.  They're required to have the same *layout* but multiple 
safepoints were supported.

p.s. Your use of the phrase "gc runtime" above is mildly ambiguous. 
Hopefully I inferred the right meaning.
>
>> - Is using gcroot and allocas to mark pointers as garbage collected
>> references valuable?  (As opposed to using address spaces on the SSA
>> values themselves?)  Long term, should we retain the gcroot marker
>> intrinsics at all?
>
> According to [1], the gcroot intrinsic was made for frontends which 
> rely on allocas and mem2reg to bring their code in a SSA form.  In 
> this case the code emitted by the frontend has the following properties:
>
> 1) The GC root is loaded from the alloca before each use.
> 2) The GC root is stored into the alloca after each assignment.
> 3) No interior pointers are passed across safepoints.
>
> The resulting code should always be correct albeit slow.  It shouldn't 
> be too hard to add a case to mem2reg which transforms gcroot'ed 
> allocas into something the late safepoint placement pass understands 
> as being a GC root.
This is harder than it might first seem, but might be doable.  I would 
strongly suggest that it not be part of mem2reg though.  :)
>
> -Manuel
>
> [1] http://llvm.org/docs/GarbageCollection.html#gcroot