[LLVMdev] Code for late safepoint placement available

[Philip Reames]

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>