Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2009-04-23 13:00:49

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