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