[LLVMdev] GC Statepoint Transition Status?

[Philip Reames]

On 05/25/2015 04:50 PM, kelvin farmer wrote:
> Hi,
>
> I am looking to utilize LLVM as the backend in an existing compiler 
> for a garbage collected language, and have a question regarding the 
> current and future support for precise GC in LLVM.
Can I ask which language?  I'm always happy to see more languages with 
GC being built on top of LLVM.
>
> It appears that gc.root is being phased out, with with breaking 
> changes such as this: http://reviews.llvm.org/D7004 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D7004&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=4mbkM2pdFMgJXWqAY5MQmQhlvEsEHXhPH5lOb3ncJZA&s=u-EyZYwFKrFL5fEkSbGflHO1EejyCHkCrJ3x0hj0DWk&e=>
>
> Does this mean that gc.statepoint is ready for primetime (or will be 
> for 3.7's release)? Also, will gc.root still be supported in 3.7 or 
> later?
gc.root will be supported through 3.7, and likely through 3.8. While I 
have made some changes to gc.root, I have tried very hard to avoid 
breaking any use case that I know of.

I can't honestly tell you that *either* gc.root or gc.statepoint is 
production ready.  Out of the two, I believe gc.statepoint is likely to 
be more stable.  More importantly, there are folks (myself included) who 
are likely to respond to gc.statepoint bugs in a fairly prompt manner.  
While I will try to look at gc.root bugs, I have to admit these are 
going to be low priority for me.  There is no one else in the community 
actively involved in maintaining gc.root either.

Personally, I would suggest you build on top of gc.statepoint.  In 
particular, start by looking at the PlaceSafepoints and 
RewriteStatepointsForGC utility passes.

My strong suggestion would be that whichever you pick, make sure you're 
setup to track tip of tree development on a semi regular basis.  You 
*will* find at least a couple of issues along the way and you really 
want to be able to pick up fixes easily.
>
> My gut tells me to use statepoints, but after seeing a bunch of TODOs 
> in its implementation in trunk (along with the docs still describing 
> it as experimental), I'm unsure which intrinsics I should be using.
If you have specific TODOs which are concerning, please point them out.  
Some may just be stale, others might be minor issues.  I can give 
context if you list the specific ones that concern you.

The experimental part isn't going away for quite a while.  I suspect we 
need to see a merger of patchpoints and statepoints before we're really 
ready to remove the experimental label.  Experimental here means "no 
backwards compatibility guarantees", not "unstable".

p.s. If you'd like to talk through a tentative design and get a feel for 
where we are in terms of GC support, I'm happy to chat on the phone for 
a bit.  Send me an email off list and we'll setup a call.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150528/35ee82a2/attachment.html>