[llvm-dev] Non-relocating GC with liveness tracking

[Sanjoy Das via llvm-dev]

+CC Philip Reames and Anna Thomas from Azul Systems

On Fri, Dec 8, 2017 at 1:29 PM, Chuan Qiu via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi Team,
> I'm working on a new pure functional language and I'm trying to add GC
> support for that.
>
> Because all vars are immutable, the IR that my frontend generates are all
> register based, i.e. no alloca, and no readmem, writemem unless
> accessing/constructing structs.
>
> If I use the traditional GC with gcroot intrinsic, it will need to emit more
> code for liveness tracking, storing the IR values into the gcroot, which
> seems convoluted.
>
> I found using stack map / statepoints very plausible here, because it only
> needs all live vars without saving it to a corresponding gcroot, and can
> track liveness at every call point.
>
> However, this seems still marked as experimental, and doesn't support
> exception handling (which is a requirement for my language). And because my
> language uses return barriar
> (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm
> already using a new intrinsic that returns a token type for calls so I can
> have multiple return paths that retrieves the actual result, and currently
> it doesn't work with gc.statepoint.
>
> I wanna check the status of statepoint GC: Is it still actively developed?
> is there any plan to fix the exception handling path? Or should I continue
> to use the gcroot intrinsic? Change my new multi-return intrinsic to support
> statepoint?
>
> I'm also thinking using a non-relocating GC with stackmap because relocating
> is currently optional for me: all live roots are passed to call site as
> operand bundle, so codegen can emit the stack map, and my new intrinsic for
> multiple return paths can also work with that.
>
> Any advise will be welcome.
>
> Thanks
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>