[LLVMdev] LLVM and managed languages

[Talin]

Would you then agree with me that "LLVM's garbage collection facilities,
_as described in the LLVM documentation_, are too difficult to use"?

On Tue, Dec 6, 2011 at 3:40 AM, Jon Harrop <
jonathandeanharrop at googlemail.com> wrote:

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


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111207/6965b4b5/attachment.html>