<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 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>
<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>
</body>
</html>