[LLVMdev] Code for late safepoint placement available

[Philip Reames]

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 
<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.)
  * 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140604/133471aa/attachment.html>