<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Forwarding a message from an old email chain to the list to make
sure it gets archived. <br>
<div class="moz-forward-container"><br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>Re: OCaml GC in LLVM</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Mon, 08 Dec 2014 14:45:39 +0300</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>Peter Zotov<br>
</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
</pre>
<br>
</div>
<br>
</body>
</html>