

Precise Garbage Collection for C [pdf] - scott_s
http://www.cs.utah.edu/~regehr/papers/ismm15-rafkind.pdf

======
dkarl
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-

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

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

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

