On LLVM’s GC Infrastructure (2013)

eschew.wordpress.com

40 points·luu··5 comments

The proposed new implementation: http://www.philipreames.com/Blog/2014/10/13/statepoint-chang....

Which I've been watching. If I remember correctly, Philip Reames stated that LLVM's precise GC support was just plain broken, although I don't remember the correspondence of what this essay talks about vs. what Reames discovered (not worth remembering something that's broken and in the process of being fixed). It's in earlier posts to his blog.

There were some interesting attempts trying to adapt LLVM's precise GC to Haskell's GC model and the difficulties with this approach: http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-w...

He essentially retracted his original assertion eight months after it was published, see the first few "Update" sections of

http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcro...

and also

http://www.philipreames.com/Blog/2014/10/21/statepoints-vs-g...

"To explicitly state this again since I screwed this up once before, both statepoints and gc.roots can correctly represent relocation semantics in the IR. In fact, the underlying reasoning about their correctness are rather similar."

Argh. I wish he'd used language like "I retract" in the more recent 10/21 post, it got into "weeds" that I was avoiding getting into until he/Team Azul finish their statepoint work. That based on his mistakes with gcroot (granted, I share his goal of high performance precise collection, which is just not in the DNA of C/C++).

And I see the first batch of patches landed today: http://www.philipreames.com/Blog/2014/12/04/statepoint-patch...

Reply on news.ycombinator.com