<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 24, 2014, at 11:17 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=windows-1252" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 02/24/2014 12:45 AM, Andrew Trick
      wrote:<br>
    </div>
    <blockquote cite="mid:EB6D85B9-9547-416A-8392-5A90BDEEFBF6@apple.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On Feb 21, 2014, at 10:37 AM, Philip Reames <<a moz-do-not-send="true" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <meta content="text/html; charset=windows-1252" 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=windows-1252" 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 moz-do-not-send="true" 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>
    </blockquote>
    Andy, I'm not clear what you're trying to say here.  Could you
    rephrase?  In particular, what do you mean by "call to invoke GC"? 
    <br></div></blockquote></div><br><div>I mean a call site that we think of as a safepoint could potentially call to the runtime and block while GC runs. We can’t let LLVM optimize hoist loads or sink stores across that call.</div><div><br></div><div>-Andy</div></body></html>