On LLVM’s GC Infrastructure (2013)(eschew.wordpress.com)

40 pointsby luuvor 12 Jahren5 comments

eschew.wordpress.com

On LLVM’s GC Infrastructure (2013)

https://eschew.wordpress.com/2013/10/28/on-llvms-gc-infrastructure/

5 comments

rayinervor 12 Jahren

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

hgavor 12 Jahren

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.

freyrs3vor 12 Jahren

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...

eschewvor 12 Jahren

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."

hgavor 12 Jahren

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...