<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 29, 2013 at 1:17 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@azulsystems.com" target="_blank">sanjoy@azulsystems.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Talin,<br>
<br>
Thank you for your response!<br>
<br>
Since you mention that you don't implement derived pointers, I'm a<br>
little confused about how your approach solves the issue I brought up.<br>
It seems to me that unless you plan on pinning some objects, support<br>
for derived pointers isn't optional.  I'm not talking about derived<br>
pointers that the front-end introduces (which can be tracked) but the<br>
ones that are introduced by llvm during IR level optimizations or,<br>
worse, during and after instruction selection.<br>
<br>
To be sure that we're talking about the same thing, as an example,<br>
consider the loop (in pseudo llvm IR):<br>
<br>
for (int i = 0 to (length - 1)) {<br>
 total += a[i];<br>
 safepoint(); // This thread may be stopped here, and `a'<br>
              // may be relocated.<br>
}<br>
<br>
llvm can transform this loop to<br>
<br>
for (int *i = &a[0] to &a[length - 1]) {<br>
 total += *i;<br>
 safepoint(); // llvm has now introduced an additional<br>
              // derived pointer, `i'.<br>
}<br>
<br>
>From llvm's point of view this is a valid transformation; but it ends<br>
up creating a new pointer the GC has to be aware of, and needs to be<br>
relocated in sync with a.</blockquote><div><br></div><div>LLVM shouldn't do this if you're using the gcroot intrinsic.  Your example would be:</div><div><br></div><div>llvm.gcroot(a) // a escapes</div><div>for (int i = 0 to length - 1) {</div>
<div>  total += a[i];</div><div>  safepoint() // a could be modified since it escaped<br>}</div><div><br></div><div>See, like Talin said, gcroot blocks a lot of optimization.  :)</div></div></div></div>