Precise Garbage Collection for C [pdf] | Hacker News Reader

Precise Garbage Collection for C [pdf]

cs.utah.edu

23 pointsscott_s4 comments

Very cool stuff, and it sounds like they nailed their original goal, which was to provide a more accurate replacement for the Boehm collector for their PLT Scheme code. But in case anyone is excited about this being a general-use solution, the first sentence hints that it won't work with most C code:

Magpie is a source-to-source transformation for C programs that enables precise garbage collection, where precise means that integers are not confused with pointers

Later, to crush your hopes completely:

Precise GC requires that a C program obeys many restrictions - the same ones that apply to using conservative GC, and more - or the program can crash. For example, to use precise GC, a C program must never extract a pointer from a variable typed as long, at least not if a collection may have occurred since the value was stored in the variable.

Yeah, definitely not going to work with any large program that has been touched by an average C programmer.

These extra constraints are, however, satisfied by normal C programming practices.

-snort-

If you are starting a project from scratch, and need GC, I would imagine it would be less of a pain (on a non-trivial bit of code) to abide by the restrictions than to have to find and plug memory leaks by hand all the time.

Sure, assuming there's no more suitable language than C, and assuming all the C libraries you use abide by the restrictions. The article says, "Library functions that are opaque to the GC remain safe as long as they do not invoke callbacks or retain copies of pointers," which helps, but isn't a complete pass. (Plus, even though C got void* before I entered elementary school, I still occasionally see library APIs that use int or long instead of void*.)

Also, the article says, "Custom allocators, in contrast, typically break these invariants permanently, because they allocate objects of statically unspecified shape in a block of primitively allocated memory." I'm not entirely sure, but it sounds like this means you can't use any library that uses a custom allocator. Certainly you'll have to manage resources from such libraries by hand. At that point you might as well use any garbage-collected language with a good C interface.

Unless, of course, you're implementing a garbage-collected language.

I agree that its application is limited (although I'm surprised they were able to convert even parts of the Linux kernel). But if I ever found myself implementing the runtime for a language with GC, I'd probably reach for this solution.

Reply on news.ycombinator.com