<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 9:35 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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. <br>
<a href="https://github.com/AzulSystems/llvm-late-safepoint-placement" target="_blank"><br>
https://github.com/AzulSystems/llvm-late-safepoint-placement</a><br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<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 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?</li>
<li>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?</li>
<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>
<li>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.)<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. 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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><ul><li>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. </li>
<li>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. </li>
<li>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. </li>
</ul>
<br>
Yours,<br>
Philip (& team)<br>
<br>
p.s. Sanjoy, one of my co-workers, will be helping to answer
questions as they arise. <br>
<br>
p.p.s. For those wondering why the current gcroot mechanism isn't
sufficient, I covered that in a previous blog post:<br>
[1] <a href="http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/" target="_blank">http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/</a><br>
</div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Talin
</div></div>