[LLVMdev] Code for late safepoint placement available
Philip Reames
listmail at philipreames.com
Fri Jun 13 09:42:53 PDT 2014
On 06/10/2014 11:23 AM, Talin wrote:
> On Wed, Jun 4, 2014 at 9:35 AM, Philip Reames
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>
> 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.
>
> Open Topics:
>
> * 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..
>
> 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.
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.
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.)
> 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.
>
> 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.
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:
http://www.philipreames.com/Blog/2014/06/12/ir-restrictions-for-late-safepoint-placement/
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.
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.
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. :)
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140613/887385c8/attachment.html>
More information about the llvm-dev
mailing list