Forwarding a message from an old email chain to the list to make sure it
gets archived.
-------- Forwarded Message --------
Subject: Re: OCaml GC in LLVM
Date: Mon, 08 Dec 2014 14:45:39 +0300
From: Peter Zotov
To: listmail at philipreames.com
On 2014-12-08 14:35, Peter Zotov wrote:> Hi Philip,
>
> I'm watching with great interest the progress of GC support
> in LLVM. I have some intermediate work on an OCaml backend for
> LLVM, and good GC intrinsics are what blocked me there.
>
> The in-tree OCaml GC implementation was never used by anything.
> It does generate frame tables compatible with ocamlopt, however
> it was added as a mere example--there is simply no existing
> code or infrastructure that could take advantage of it.
> It's also blitheringly inefficient, so remove at will.
>
> I think the Erlang GC is used by HiPE.
Following up with the answers to your questions:
> 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.
Certainly. I would use that in an OCaml LLVM backend.
This will allow me to reuse unmodifed OCaml runtime, and even mix and
match LLVM-built and ocamlopt-built code.
> - 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.
I do not need this.
> - 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?
Address spaces make my codegen much simpler.
--
Peter Zotov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150927/e98f8590/attachment.html>