<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/24/2014 01:48 PM, Andrew Trick
wrote:<br>
</div>
<blockquote
cite="mid:18C418BF-4FBA-4F63-B206-8557FC95FF48@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Feb 24, 2014, at 1:26 PM, 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/24/2014 11:27 AM, Andrew
Trick wrote:<br>
</div>
<blockquote
cite="mid:55360371-0016-4770-9AAC-536DB45D0269@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Feb 24, 2014, at 11:17 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/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>
</blockquote>
Ah, okay. I think get where you're coming from. <br>
<br>
For call safepoints, if you assume the call itself prevents
the optimization, you're mostly okay. This is problematic
if you want to have a safepoint on a read-only call (for
example), but could be hacked around. <br>
<br>
The problem comes up with backedge, function entry, and
function return safepoints. Given there is no example in
tree (or out of tree that I know of) which uses these, it's
a little hard to tell how it's supposed to work. My belief
is that the findCustomSafePoints callback on GCStrategy is
supposed to insert these. The problem is that this pass is
a MachineFunction pass and this runs long after
optimization. <br>
</div>
</blockquote>
<div><br>
</div>
I claim that findCustomSafePoints needs to be limited to
non-readonly calls. If you don’t already have a call where you
want a safepoint, you need to insert one early, before
optimization, as you say below.</div>
</blockquote>
I think we're in agreement here with regards to correctness.<br>
<br>
I'll note for the record, two points:<br>
1) Early safepoint placement does not appear to be the intended
usage of gcroot from the documentation.<br>
2) Doing early safepoint insertion is really really bad for
optimization/performance. Consider:<br>
<br>
int sum = 0;<br>
for(int i = 0; i < 2000; i++) {<br>
sum++;<br>
gc_safepoint();<br>
}<br>
<br>
<blockquote
cite="mid:18C418BF-4FBA-4F63-B206-8557FC95FF48@apple.com"
type="cite">
<div><br>
</div>
<div>-Andy</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The alternate approach - which I believe you're assuming -
is to insert calls for each safepoint explicitly before
optimization. (In the blog post, I refer to this as "early
safepoint insertion".) Unless I'm badly misreading both
documentation and code, that's not how gcroot is expecting
to be used. I agree that e.s.p. would work from a
correctness standpoint for the first example I listed. It
doesn't solve the second case though.<br>
<br>
Philip<br>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>