[LLVMdev] Future plans for GC in LLVM

[Manuel Jacob]

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.

> - 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).

> - 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.

-Manuel

[1] http://llvm.org/docs/GarbageCollection.html#gcroot