Would you then agree with me that "LLVM's garbage collection facilities, _as described in the LLVM documentation_, are too difficult to use"?<br><br><div class="gmail_quote">On Tue, Dec 6, 2011 at 3:40 AM, Jon Harrop <span dir="ltr"><<a href="mailto:jonathandeanharrop@googlemail.com">jonathandeanharrop@googlemail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Talin wrote:<br>
> Jon wrote:<br>
<div class="im">> > Talin wrote:<br>
> > > Garbage collection is still way too difficult.<br>
> ><br>
> > This is completely untrue.<br>
><br>
</div>> I'm afraid I'm going to have to disagree...<br>
<br>
I failed to get my point across. You're still talking about the difficulty<br>
of using LLVM's GC support. I was talking about circumventing it. The shadow<br>
stack HLVM uses does not work as you describe and it makes no use of LLVM's<br>
GC support, e.g. the llvm.gcroot() intrinsic. This is precisely why it is so<br>
much easier to write a working accurate garbage collector as I described. It<br>
doesn't have to be hard. You made a rod for your own back by choosing to use<br>
LLVM's own GC support.<br>
<div class="im"><br>
> This avoids the need to update a global variable<br>
<br>
</div>Or you could change the calling convention to pass the shadow stack pointer<br>
around.<br>
<br>
> ...you have to re-implement it for each different processor<br>
<br>
Not with the approach HLVM uses, which is completely platform and<br>
architecture agnostic.<br>
<div class="im"><br>
> None of the rest of what I'm about to say would make any difference if I<br>
was<br>
> using shadow stack. That's not where the problems lie.<br>
<br>
</div>That is not true. I believe because you are using "shadow stack" to refer<br>
only to the shadow stack that LLVM provides and not to the concept in<br>
general.<br>
<div class="im"><br>
> The main problem, as I see it, is the design of the llvm.gcroot()<br>
intrinsic.<br>
<br>
</div>HLVM does not use llvm.gcroot() so any design flaws in it are circumvented.<br>
<div class="im"><br>
> A second problem is that you are required to explicitly declare as stack<br>
root not<br>
> only your local variables, but any intermediate results of expression. In<br>
other<br>
> words, the "root-ness" of a value doesn't automatically follow along with<br>
the<br>
> value, as it would with a type-based approach. The result is that the<br>
frontend<br>
> ends up generating horrible, horrible code that is littered with extra<br>
allocas, calls<br>
> to llvm.gcroot(), and lots of extra loads and stores.<br>
<br>
</div>Again, that problem does not exist with the approach HLVM uses. It does no<br>
unnecessary allocas and makes no calls to llvm.gcroot() at all.<br>
<div class="im"><br>
> A third problem is that the optimizer *has* to know about garbage<br>
collection,<br>
> because the optimizer can do things that might invalidate your garbage<br>
> collector's assumptions.<br>
<br>
</div>And again, that problem does not exist with the approach HLVM uses. Its<br>
generated code is basically a valid C program so a correct optimizer cannot<br>
break it by violating its assumptions because there are no such assumptions.<br>
<div class="im"><br>
> I don't know what you mean by "highly experimental GC support".<br>
<br>
</div>I mean it is not tried and tested. How many people have built working<br>
garbage collectors using LLVM's support?<br>
<div class="im"><br>
> Increasing performance is only half of the story. The other half is making<br>
it<br>
> easy to use.<br>
<br>
</div>HLVM's approach is very easy to use. Therefore, improved LLVM GC support<br>
would only be valuable if it generated significantly more efficient code. In<br>
theory it should be more efficient but that has not yet been demonstrated.<br>
<br>
Cheers,<br>
<font color="#888888">Jon.<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Talin<br>