That's actually pretty cool; I remember the joy when my own malloc/free ran without crashing real-world programs; doing the same witha GC would be both satisfying and a good way to find bugs.
I've actually used this system as a student in a programming language design class, in which we had to implement semispace and mark-and-sweep collectors. I had the misfortune (unique in 2 sections of the class that semester) of running into a bug in the framework, but I believe that got fixed, and it was otherwise pretty dang cool.
We used C++ to write a game and _SOMEHOW_ without knowing properly about how GC worked - learned to write our own garbage collectors for projectiles that went out of screen and enemies that died.
:) It was basically the eye opener for how GC's worked. Though I am sure it's faaaaaar more complicated than the Sets we used to keep track. It still made me better at manually handling memory.
That being said, I prefer GC and/or Automatic Reference Counting at compile time. Still though, it was a nice "feeling" to manage your own memory in an (incredibly small) project.
He's probably talking about ARC for Objective-C, that automatically releases references and allocations when it's impossible for those allocations to be used again in scope.
That looks like a great tool! I recently took a class in programming language design where we had to implement a simulated Treadmill garbage collector using a circular linked list in Java. It taught us the basics of how the algorithm works but not really how it functions within the context of an actual programming language implementation.
The proposed framework looks like it has a lot of potential.
Brown PLT is jokingly said to do every programming language research unrelated to the type theory (not saying the type theory is unimportant of course). I hope to see more researches and directions like that.
