[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.
 >
[snip]

There's also the newgroup:

   gmane.comp.programming.garbage-collection.general

which is subscribable from http://news.gmane.org/

[snip]
 >
 > Felix collector is exact but has several serious problems:
 >
[snip]
 >
 > 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:

   http://www.di.unipi.it/~attardi/software.html

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

   http://tinyurl.com/8wwtw

which is tested in:

   http://tinyurl.com/exv9f

which contains:

   SELECTED_FIELDS_DESCRIPTION_OF_RECORD(desc_one_type)

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

http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt

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

   descriptor_builder<FieldsVisitor,Record>::ptr

defined in:

   http://tinyurl.com/8slwc

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:

   SELECTED_FIELDS_DESCRIPTION_OF_RECORD(GC_TYPE)

[snip]
 >
 > 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.

-regards,
Larry



More information about the Gc mailing list