On Sun, Dec 30, 2012 at 2:17 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 30 Dec 2012, at 01:54, Talin wrote:<br>
<br>
> I completely agree with your point about wanting to be able to attach GC metadata to a type (rather than attaching it to a value, as is done now). In the past, there have been two objections to this approach: first, the overhead that would be added to the Pointer type - the vast majority of LLVM users don't want to have to pay an extra 4-8 bytes per Pointer type. And second, that all of the optimization passes would have to be updated so as to not do illegal transformations on a GC type.<br>


<br>
</div>There are two other alternatives:<br>
<br>
- Use address spaces to separate garbage-collected from non-garbage-collected pointers.  There is (was?) a plan to add an address space cast instruction and explicitly disallow bitcasts of pointers between address spaces.  This would mean that you could have one address space for GC roots, one for GC-allocated memory and enforce the casts in your front end.  Optimisations would then not be allowed to change the address space of any pointers, so the GC status would be preserved.  GC-aware allocations may insert explicit address space casts, where appropriate.<br>

</blockquote><div><br></div><div>This works fine for languages like Java where every object has a type field that describes how to trace it. However, the existing LLVM intrinsics also support the case where the type information is only known statically by the compiler instead of at runtime - the metadata argument allows the compiler to pass a trace table to the GC plugin. Trying to encode that information  into a single address space integer would be painful. </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Add a new GC'd pointer type, which is an entirely separate type.  This might make sense, as you ideally want GC'd pointers to be treated differently from others (e.g. you may not want pointers to the starts of allocations to be removed)<br>


<br>
For languages like OCaml, you also want to be able to do escape analysis on GC'd pointers to get good performance (so you don't bother tracing ones that can't possibly escape).  This ideally requires a pass that will recursively and automatically apply nocapture attributes to arguments.  In functional languages, this ends up being almost all allocations, so you can allocate them either on the stack or on a separate bump-the-pointer allocator and delete them on function return by just resetting the pointer.  This means that you would want to be able to have transforms that lowered GC'd pointers to stack or heap pointers.<br>


<br>
In some implementations, GC'd pointers are fat pointers, so they should not be represented as PointerType in the IR or as iPTR in the back end.<br>
<span class="HOEnZb"><font color="#888888"><br>
David</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Talin