[Gc] Re: integrating collection strategies
cppljevans at cox-internet.com
Thu Nov 24 08:17:20 PST 2005
On 11/22/2005 11:28 PM, skaller wrote:
> On Tue, 2005-11-22 at 17:34 -0800, Boehm, Hans wrote:
>>You might be better off posting such general questions to
>>gclist at iecc.com.
There's also the newgroup:
which is subscribable from https://news.gmane.org/
> Felix collector is exact but has several serious problems:
> To solve these problem I plan to use a variety of techniques.
> One is: Boehm in malloc/free replacement mode.
> Another is: Native use of Boehm collector as well as Felix one
> Third: replace Felix collector with Boehm collector.
> These combinations can solve different problems in different
> ways with different outcomes and have different implementation
Why not adapt the Customizable Memory Management code:
? It has a conservative heap, which could be used for
the C code, but it also has a copy collector which
is precise with some programmer help. This help involves
defining a virtual CmmObject::traverse method. Since
Felix is precise, I assume it would be possible to define
this traverse method in Felix for each gc'ed class.
> It is not possible for the compiler to construct a bitmap,
> because the offsets are only known symbolically at Felix
> compile time. So I would have to equip Felix with additional
> language facilities to allow/enforce specification of
> object sizes to permit this. The alternative is runtime
> construction of the bitmap .. either on every allocation,
> or once at startup (which leads to nasty questions about
> relocatable code, thread safety, etc ..)
OOPS. I guess the "only known symbolically" phrase means the above
suggestion Felix and CmmObject::traverse is not right.
The "once at startup" question is one that's bothered me about
the precise method at:
which is tested in:
which is where the "once at startup" occurs. Actually, it
occurs the first time the pointer descriptor, similar to
is accessed. This is because the pointer descriptor is stored as a
static variable, the_builder, inside a static function:
Anyway, my point is CMM can be used with the fields_visitor library
in boost/sandbox to automate creation of a replacement for CMM's
virtual traverse. Furthermore, a gc'ed object need not be derived
from CmmObject; however, a dummy object for each gc'ed type, GC_TYPE,
must be created with the macro invocation:
> Meaning: there is some effort getting Boehm to work
> right, even when you're specifically using it and have
> absolute control of everything. Unlike Neko, Felix is
> designed to cooperate with raw C/C++ .. dynamic loading
> and threads too. So it isn't clear what the tradeoffs
> will be in which combinations of techniques: the Felix
> collector has advantages in some applications, particularly
> those running large numbers of independent microthreads,
> with real time demands (since the collection can be localised).
Please let me know if there's some way I could help
in this endeavor.
More information about the Gc