[LLVMdev] LLVM and managed languages

[Jon Harrop]

Yes, absolutely. And I agree completely that a toolkit demonstrating just
how easy it is to create garbage collected virtual machines and languages
using LLVM would be awesome but, if you want to describe a practical
approach to getting started quickly, it should be using the approach HLVM
uses and not LLVM's GC support.

 

Cheers,

Jon.

 

From: Talin [mailto:viridia at gmail.com] 
Sent: 07 December 2011 19:14
To: Jon Harrop
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] LLVM and managed languages

 

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/20111210/bdf2bf8c/attachment.html>