<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jon.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Talin [mailto:viridia@gmail.com] <br><b>Sent:</b> 07 December 2011 19:14<br><b>To:</b> Jon Harrop<br><b>Cc:</b> LLVM Developers Mailing List<br><b>Subject:</b> Re: [LLVMdev] LLVM and managed languages<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Would you then agree with me that "LLVM's garbage collection facilities, _as described in the LLVM documentation_, are too difficult to use"?<o:p></o:p></p><div><p class=MsoNormal>On Tue, Dec 6, 2011 at 3:40 AM, Jon Harrop <<a href="mailto:jonathandeanharrop@googlemail.com">jonathandeanharrop@googlemail.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal>Talin wrote:<br>> Jon wrote:<o:p></o:p></p><div><p class=MsoNormal>> > Talin wrote:<br>> > > Garbage collection is still way too difficult.<br>> ><br>> > This is completely untrue.<br>><o:p></o:p></p></div><p class=MsoNormal>> 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.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>> This avoids the need to update a global variable<o:p></o:p></p></div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><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.<o:p></o:p></p></div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>> The main problem, as I see it, is the design of the llvm.gcroot()<br>intrinsic.<o:p></o:p></p></div><p class=MsoNormal>HLVM does not use llvm.gcroot() so any design flaws in it are circumvented.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><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.<o:p></o:p></p></div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><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.<o:p></o:p></p></div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>> I don't know what you mean by "highly experimental GC support".<o:p></o:p></p></div><p class=MsoNormal>I mean it is not tried and tested. How many people have built working<br>garbage collectors using LLVM's support?<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>> Increasing performance is only half of the story. The other half is making<br>it<br>> easy to use.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>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><span style='color:#888888'>Jon.<br><br></span><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <br>-- Talin<o:p></o:p></p></div></div></body></html>