[Gc] sanity check please

Clyde Kessel clyde at progress.com
Thu Mar 18 09:13:01 PST 2004

I am hoping someone can tell me if the following plan is reasonable and
has a chance of working.
We have a large commercial product written in C++ on WIN32 using Visual
C++ 6.0.  It consists of several .EXE and .DLL files as well as various
3rd party modules in C, C++ and Java.
One particular subsystem (which is 95% confined to a single .DLL) needs
a garbage collector, so our plan is as follows.
1) We have downloaded V6.2 of the garbage collector.
2) Build the GC directly into that .DLL for use by a particular set of
objects in that .DLL.  Some of the objects in that .DLL will inherit
from class gc and be allocated in collectable memory, some not.  This
should require extremely few changes to the source code.  All the
objects we want to be collectable already inherit from a base class
which will itself inherit from class gc.  This localizes the changes to
a single .h file.  In a few cases, those collectable objects are also
created in other .DLL files.  Can they be collectable as well?  The rest
of the system will continue to use the standard malloc & free.
3)The target .DLL runs a single thread, although the rest of the system
is generally multi-threaded.  We also use multi-thread DLL C runtime
library everywhere.  Can we build the GC single-thread, or do we need to
use the multi-thread support from the start?
4) As we build experience and confidence with the garbage collector, we
will migrate it to its own .DLL and gradually start using it more widely
in the rest of the system.
5) When compiling our code with gc_cpp.h in the Win32 Debug
configuration with
     #define new DEBUG_NEW    (this activates the Windows MFC leak
detector), we found some of the templates for operator new and operator
new[] were incorrect or missing.  Specifically, we needed to add
templates and implementations for 
      gc::operator new(size_t, const char *, int) and the same for 
      gc::operator new[]
      ::operator new
      ::operator new[]
The ::operator new(size_t, int, const char *, int) in gc_cpp.h seems to
be trying to address this problem. Ifso, it is incorrect and
Are we making some horrible mistake?
Thanks very much
Clyde Kessel
clyde at progress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20040318/7304e683/attachment.html

More information about the Gc mailing list