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 variableOr you could change the calling convention to pass the shadow stack pointer around.> ...you have to re-implement it for each different processorNot 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 Iwas> 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 stackroot not> only your local variables, but any intermediate results of expression. Inother> words, the "root-ness" of a value doesn't automatically follow along withthe> value, as it would with a type-based approach. The result is that thefrontend> ends up generating horrible, horrible code that is littered with extraallocas, 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 garbagecollection,> 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 makingit> 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.
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>
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 variableOr you could change the calling convention to pass the shadow stack pointer around.> ...you have to re-implement it for each different processorNot 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 Iwas> 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 stackroot not> only your local variables, but any intermediate results of expression. Inother> words, the "root-ness" of a value doesn't automatically follow along withthe> value, as it would with a type-based approach. The result is that thefrontend> ends up generating horrible, horrible code that is littered with extraallocas, 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 garbagecollection,> 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 makingit> 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>