<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 21, 2014, at 10:37 AM, Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 02/14/2014 05:55 PM, Philip Reames
      wrote:<br>
    </div>
    <blockquote cite="mid:52FEC90C.3030905@philipreames.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      Splitting out a conversation which started in "make DataLayout a
      mandatory part of Module" since the topic has decidedly changed. 
      This also relates to the email "RFC: GEP as canonical form for
      pointer addressing" I just sent.  <br>
      <br>
      <div class="moz-cite-prefix">On 02/10/2014 05:25 PM, Nick Lewycky
        wrote:<br>
      </div>
      <blockquote cite="mid:CADbEz-gPTzM0saPA5X9_SM0mqTyARaeTE77=a75fm9cSu5J4yw@mail.gmail.com" type="cite">
        <div dir="ltr">
          <div class="gmail_extra">
            <div class="gmail_quote">
              <div>...<br>
                <br>
                We're supposed to have the llvm.gcroots intrinsic for
                this purpose, but you note that it prevents gc roots
                from being in registers (they must be in memory
                somewhere, usually on the stack), and that fixing it is
                more work than is reasonable.<br>
              </div>
            </div>
          </div>
        </div>
      </blockquote>
      This is slightly off, but probably close to what I actually said
      even if not quite what I meant.  :)<br>
      <br>
      I'm going to skip this and respond with a fuller explanation
      Monday.  I'd written an explanation once, realized it was wrong,
      and decided I should probably revisit when fully awake.  <br>
      <br>
      Fundamentally, I believe that gc.roots could be made to work, even
      with decent (but not optimal) performance in the end.  We may even
      contribute some patches towards fixing issues with the gc.root
      mechanism just to make a fair comparison.  I just don't believe
      it's the right approach or the best way to reach the end goal.<br>
    </blockquote>
    So, not quite on Monday, but I did get around to writing up an
    explanation of what's wrong with using gcroot.  It turned out to be
    much longer than I expected, so I turned it into a blog post:<br>
    <a class="moz-txt-link-freetext" href="http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/">http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/</a><br>
    <br>
    The very short version: gcroot loses roots (for any GC) due to bad
    interaction with the optimizer, and gcroot doesn't capture all
    copies of a pointer root which fundamentally breaks collectors which
    relocate roots.  The only way I know to make gcroot (in its current
    form) work reliably for all collectors is to insert safepoints very
    early, which has highly negative performance impacts.  There are
    some (potentially) cheaper but ugly hacks available if you don't
    need to relocate roots.  <br>
    <br>
    There's also going to be a follow up post on implementation
    problems, but that's completely separate from the fundamental
    problems.  <br></div></blockquote><div><br></div>Thanks for the writeup. FWIW my understanding of gcroot has always been that the call to invoke GC is “extern” and not readonly, so we can’t do store->load forwarding on the escaped pointer across it. I have never used gcroot myself.</div><div><br></div><div>-Andy</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    Philip<br>
    <br>
  </div>

_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></body></html>