[Gc] Re: integrating collection strategies

Larry Evans 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
 > consequences.

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 contains:


which is where the "once at startup" occurs.  Actually, it
occurs the first time the pointer descriptor, similar to
GC_descr in:


is accessed.  This is because the pointer descriptor is stored as a
static variable, the_builder, inside a static function:


defined in:


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 mailing list