3 ms·
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
by javanix 17y ago
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 17y agoSure, 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 17y agoUnless, 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.