[gclist] Re: gclist-digest V3 #9

[Michael Spertus]

At 06:05 AM 4/14/99 -0400, gclist-digest wrote:
>
>gclist-digest        Wednesday, April 14 1999        Volume 03 : Number 009
>
>
>
>In this issue:
>
>    [gclist] Detlef's Run-time Typing RCMap
>    [gclist] Boehm collector and parallel Boehm collector - opinions
>    Re: [gclist] Detlef's Run-time Typing RCMap
>
>----------------------------------------------------------------------
>
>Date: Tue, 13 Apr 1999 16:36:42 EDT
>From: Cppljevans@aol.com
>Subject: [gclist] Detlef's Run-time Typing RCMap
>
>In the article "Garbage Collection and Run-time Typing as a C++ Library" 
>(from the _1992 Usenix C++ Conference Proceedings_) David L. Detlef
described 
>a method of generating a map of internal pointers, RCMap, for each garbage 
>collected c++ class without compiler support.  However, I've been unable to 
>find anyone else using this method.  In particular, Attardi's "A
Customizable 
>Memory Management Framework" from the 1994 USENIX C++ Conference 
>Proceedings_, does not mention this article; yet, Attardi's implementation 
>has, in file cmm.cpp, a method, GmmObject::getFieldTable, which is 
>essentially Detlef''s RCMap.  However, this is optionally included in the 
>source (via #if..#endif), and I didn't find how he calculated this. This
code 
>is at /pub /project /posso /cmm /cmm-1-9.tgz at ftp.di.unipi.it .  
>
>Would someone please give me some reference or source code which uses 
>Detlef's method, or can anyone explain some flaws in the method which might 
>explain why it has not been used?  I'm currently implementing the method and 
>would also like to know of any improvements.
>
>Thanks for any help.
>
We implemented a smart pointer based collector using Detlef's approach,
which we offered commercially along with a transparent conservative
collector based on a greatly modified version of the Boehm collector. We
pretty quickly found out that both from a customer and a technical point of
view that the transparent approach was superior, and we now only sell the
conservative collector, called Great Circle (see http://www.geodesic.com).
The technical reasons were primarily as follows:

Hard To Use:
============
Requiring the use of smart pointers is very invasive. In particular, it is
virtually impossible to use smart pointers to garbage collect 3rd-party
libraries, C code, and preexisting applications.

By contrast, the conservative collector is completely transparent,
requiring no code changes or even recompilation. Memory leaks just disappear.

Poor Performance:
=================
Detlefs' approach has poor performance. Every time a pointer is created, a
test has to be run to determine whether to build a map. Furthermore,
compilers often fail to enregister smart pointers, making dereferencing
very expensive. It is especially difficult to achieve reasonable
performance in multi-threaded environments. I believe that Detlef's paper
mentions that he also received rather poor performance.

By contrast, the conservative collector is extremely high performance. Most
programs run faster with Great Circle than without it.

All this being said, our smart pointer collector is a commercial strength
C++ implementation that solves some problems that remained in the Detlefs'
paper, such as Polymorphism of smart pointers and generation of maps for
classes without default constructors. If you would still like access to its
source, please contact me directly.

Michael Spertus                            mps@geodesic.com
Geodesic Systems                           (312) 832-2039
414 N Orleans, Suite 410                   http://www.geodesic.com
Chicago, IL 60610