[LLVMdev] Code for late safepoint placement available

[Talin]

On Wed, Jun 4, 2014 at 9:35 AM, Philip Reames <listmail at philipreames.com>
wrote:

>  As I've mentioned on the mailing list a couple of times over the last few
> months, we've been working on an approach for supporting precise fully
> relocating garbage collection in LLVM.  I am happy to announce that we now
> have a version of the code available for public view and discussion.
>
> https://github.com/AzulSystems/llvm-late-safepoint-placement
>
> Our goal is to eventually see this merged into the LLVM tree.  There's a
> fair amount of cleanup that needs to happen before that point, but we are
> actively working towards that eventual goal.
>
> Please note that there are a couple of known issues with the current
> version (see the README).  This is best considered a proof of concept
> implementation and is not yet ready for production use.  We will be
> addressing the remaining issues over the next few weeks and will be sharing
> updates as they occur.
>
> In the meantime, I'd like to get the discussion started on how these
> changes will eventually land in tree.  Part of the reason for sharing the
> code in an early state is to be able to build a history of working in the
> open, and to to able to merge minor fixes into the main LLVM repository
> before trying to upstream the core changes.  We are aware this is a fairly
> major change set and are happy to work within the community process in that
> regard.
>
> 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 factor the core GC support for review?  Our current
>    intent is to separate logically distinct pieces, and share each layer one
>    at a time.  (e.g. first infrastructure enhancements, then intrinsics and
>    codegen support, then verifiers, then safepoint insertion passes)  Is this
>    the right approach?
>    - How configurable does the GC support need to be for inclusion in
>    LLVM?  Currently, we expect the frontend to mark GC pointers using address
>    spaces.  Do we need to support alternate mechanisms?  If so, what interface
>    should this take?
>    - 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..
>     - What programmatic interface should we present at the IR level and
>    where should it live?  We're moving towards a CallSite like interface for
>    statepoints, gc_relocates, and gc_results call sites.  Is this the right
>    approach?  If so, should it live in the IR subtree, or Support?  (Note: The
>    current code is only about 40% migrated to the new interface.)
>
> 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. 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.

>
>    - To support invokable calls with safepoints, we need to make the
>    statepoint intrinsic invokable.  This is new for intrinsics in LLVM.  Is
>    there any reason that InvokeInst must be a subclass of CallInst? (rather
>    than a view over either calls or invokes like CallSite)  Would changes to
>    support invokable intrinsics be accepted upstream?  Alternate approaches
>    are welcome.
>    - Is the concept of an abstract VM state something LLVM should know
>    about?  If so, how should it be represented?  We're actively exploring this
>    topic, but don't have strong opinions on the topic yet.
>    - Our statepoint shares a lot in the way of implementation and
>    semantics with patchpoint and stackmap.  Is it better to submit new
>    intrinsics, or try to identify a single intrinsic which could represent
>    both?  Our current feeling is to keep them separate semantically, but share
>    implementation where possible.
>
>
> Yours,
> Philip (& team)
>
> p.s. Sanjoy, one of my co-workers,  will be helping to answer questions as
> they arise.
>
> p.p.s. For those wondering why the current gcroot mechanism isn't
> sufficient, I covered that in a previous blog post:
> [1] http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140610/3dbfed8b/attachment.html>