

On LLVM’s GC Infrastructure (2013) - luu
https://eschew.wordpress.com/2013/10/28/on-llvms-gc-infrastructure/

======
rayiner
The proposed new implementation:
[http://www.philipreames.com/Blog/2014/10/13/statepoint-
chang...](http://www.philipreames.com/Blog/2014/10/13/statepoint-changes-up-
for-review).

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

~~~
eschew
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...](http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/)

and also

[http://www.philipreames.com/Blog/2014/10/21/statepoints-
vs-g...](http://www.philipreames.com/Blog/2014/10/21/statepoints-vs-gcroot-
for-representing-call-safepoints/)

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

~~~
hga
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...](http://www.philipreames.com/Blog/2014/12/04/statepoint-patches-have-
landed/)

