Sid Sacek wrote:
There is one feature of an advanced GC that is super-beneficial to me however. The C++/CLI garbage collector has the ability to perform data compaction. Basically, when the GC activates, it removes the unused objects, and then fills in the vacated memory gaps with existing live objects, thus compressing memory usage. This ability can help you create applications that can run 24/7 ( basically forever ) without having any memory fragmentation. This to me is a better feature of the garbage collector. I personally don't know how the CLI engine performs this neat trick but it works, and the code generated by the compiler is crisp, compact and efficient. I don't know if there's a C++ based GC library out there that does this sort of thing.
Compacting (or otherwise moving) garbage collectors require detailed knowledge. They must know where the pointers to the moved objects are and modify them. Conservative GCs do not know this. They assume that every value that could be a pointer to an object actually is one. This works as long as they're read-only, i.e. they just look where the pointers are. Once they start modifying (as a moving GC would), this is no longer sufficient. Previously, the only danger was that an object would live longer than it should. Now, the GC could silently and not really deterministically modify miscellaneous values in the program. You can't implement a moving GC as a library unless the language already offers detailed type information, stack maps, register maps, and strict type safety. C++ doesn't do any of these things by default, and even an implementation generating the first three would have trouble with the fourth. Sebastian