<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 06/10/2014 11:23 AM, Talin wrote:<br>
</div>
<blockquote
cite="mid:CABwJDdmHxNip4do=KpfvjRGYimJOYkW9sh0H+nzXRwrogaVcCA@mail.gmail.com"
type="cite">
<div dir="ltr">On Wed, Jun 4, 2014 at 9:35 AM, Philip Reames <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
I've included a list of specific questions I know we'd
like to get feedback on, but general comments or
questions are also very welcome. <br>
<br>
Open Topics:<br>
<ul>
<li>How should we approach removing the existing
partial support for garbage collection? (gcroot) Do
we want to support both going forward? Do we need
to provide a forward migration path in bitcode?
Given the usage is generally though MCJIT, we would
prefer we simply deprecate the existing gcroot
support and target it for complete removal a couple
of releases down the road.. <br>
</li>
</ul>
</div>
</blockquote>
<div>Chris and I had a discussion about 3 years ago where we
talked about keeping both, but it really depends on how
difficult it is. </div>
</div>
</div>
</div>
</blockquote>
First, did I trim the response correctly? It sounds like you're
responding to the question of how to integrate late safepoint
placement with gcroot, but your actual response was inlined after
another unrelated question. <br>
<br>
Honestly, other than the maintenance headache, the two code paths
basically don't touch. Keeping both is entirely viable, though I'd
have to ask: why? What benefit does gcroot have? (You started
addressing this already, just making the question explicit.)<br>
<blockquote
cite="mid:CABwJDdmHxNip4do=KpfvjRGYimJOYkW9sh0H+nzXRwrogaVcCA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Although the existing intrinsics have many different
kinds of horribleness, the one advantage that they have is
that roots don't have to be pointers - they can be structs
containing pointers, such as tagged unions or Go-style
interface values, which have fields that may contain
either a pointer or some other data type depending on the
value of some other field. I know we talked in email about
ways to work around this limitation, but those workarounds
have some complex edge cases which it would be nice to
avoid - like for example passing a tagged union as a
parameter.</div>
<div><br>
</div>
<div>That being said, I'm probably the only person who cares
about this particular issue :) And while removing support
for non-pointer roots will make my life harder in some
ways, the new system will make it easier in many other
ways.</div>
</div>
</div>
</div>
</blockquote>
For those who weren't part of the previous discussion, I summarized
the subset of IR which our safepoint placement scheme handles in
this blog post:
<a class="moz-txt-link-freetext" href="http://www.philipreames.com/Blog/2014/06/12/ir-restrictions-for-late-safepoint-placement/">http://www.philipreames.com/Blog/2014/06/12/ir-restrictions-for-late-safepoint-placement/</a><br>
<br>
Short version as it applies to Talin's point: We do not currently
support pointers to garbage collected objects in aggregate types.
This should be fairly straight forward to add. Patches are welcome
and we should support them at some point. We have no plans to
support tagged unions as roots. If you're willing to bake in
knowledge of the tag functions, doing so wouldn't be particularly
hard, but I don't know of any way to do so in a general way. <br>
<br>
One easy to implement support for aggregate types would be to
explode and reconstruct the aggregate over the safepoint. A more
efficient, but also more complicated, scheme would be to encode the
interior reference to the aggregate type into the arguments of the
statepoint intrinsic. Both schemes suffer from the fact they have
to rely on type information (of the aggregate itself) being
accurate. This is a stronger assumption than we currently need for
non-aggregates and we would need to verify that the optimizer
actually upheld it. <br>
<br>
Talin, hopefully my restatement above helps clarify. I'll also note
that tagged unions as parameters are fine if the values are
extracted immediately on entry before any safepoint happens. The
safepoint mechanism only considers values which are live (have
potential uses reachable from) the safepoint itself. As a result,
dead tagged unions are fine. Admittedly, that's a bit of a hack,
but you might find it a useful hack. :)<br>
<br>
Philip<br>
<br>
<br>
</body>
</html>