[gclist] Two conservative collectors
Thu, 11 Nov 1999 15:36:15 -0800
[I'm the primary author of the other collector. Disclaimers similar to
I think Mike presented the trade-off well. I'd just like to add a couple of
- This isn't really relevant to the original question, but there is
generally a difference in platform support between the two collectors.
Geodesic has invested a lot of energy into win32, and they support the major
commercial Unix variants. I have a lot less resources to invest, but I tend
get code contributions to support open source and many more esoteric
My own development these days is mostly on Linux, which I believe Geodesic
- These days, I personally look at win32 only if something looks clearly
and nobody else is supplying a fix. Our collector does not deal explicitly
pointers hidden outside the address space visible to the collector. I think
current collector is usable with win32 but, aside from very simple
you will need to do more than relink or recompile. I generally test
occasionally on one
win32 platform (usually a somewhat obsolete Windows 95 machine at my house).
- There is also a way to build our collector to intercept malloc, though I
works at most partially under win32. Thus Mike's statement is the correct
answer to the original
I personally also believe that the choice of collector really depends on
I was very happy to see Geodesic offer their collector, since it provides an
for people who need a commercially supported product, with everything that
I believe the basic interface differences between the collectors are still
such that they could
be hidden by a few macro definitions. I suspect it's quite feasible to make
the choice on
a per-platform basis. (There are more profound differences in some of the
features and debugging and tuning hooks.)
All of this is my own opinion, not necessarily Hewlett-Packard's position.
(If it has one,
I haven't been here long enough to discover what it is.)
From: Michael Spertus [mailto:firstname.lastname@example.org]
Sent: Thursday, November 11, 1999 7:16 AM
Subject: Re: [gclist] Two conservative collectors
At 06:05 AM 11/11/99 -0500, you wrote:
>Date: Wed, 10 Nov 1999 14:55:25 -0500
>From: "Michael T. Richter" <email@example.com>
>Subject: [gclist] Two conservative collectors.
>I'm looking into the possibility of adding garbage collection (masquerading
>it as "run-time leak detection and correction" to managers convinced that
>GC is evil) to a C++ project. I'd like to minimize the impact adding such
>GC to projects would entail. This had led me to looking into conservative
>I've tracked down two conservative collectors which will work in the Win32
>environment: the Boehm-Demers-Weiser collector at
>http://reality.sgi.com/boehm_mti/gc.html and the Great Circle collector at
>I'd like to get a feel for the costs of integrating either of these
>packages into existing code. Can either of them be used "out of the box"
>with no source code changes whatsoever for at least a start? How
>reliable/unreliable are either of these? How configurable are either of
>these? I'm soliciting opinions both good and bad.
>I'm also interested in any comparative analyses people with experience in
>both may have to offer. The BDW collector is free, so what precisely does
>Great Circle value-add that makes it worth its purchase price (whatever
>that price is -- alarm bells go off when I see "runtime license fee" and no
>pricing information on a web site....).
(Disclaimer: I am from Geodesic, the company that sells Great
Circle. Also, I am not all that familiar with whatever enhancements are in
the most recent Boehm collector, so Hans should pipe in if I miss
anything). We believe that Great Circle offers several valuable benefits
for the type of situation you have described:
(1) Great Circle can be used "out of the box" with no source changes
whatsoever or even recompilation (It helps to be able to relink the main
app but even that is not strictly necessary). Great Circle also
automatically intercepts calls to malloc/new made by 3rd-party DLLs even if
source is unavailable. By contrast, I believe in the Boehm collector, you
need to modify your code to call GC_malloc, say by "#define malloc
GC_malloc", which requires much more rebuilding and cannot garbage collect
components that you don't have source for.
(2) Great Circle includes full-featured web-based reporting. We report in
real-time on the leaks we fix with full symbolic stack traces in your web
browser as the program is running. Much other useful information including
full heap profiling is reported as well. This feature can be very useful
for increasing the confidence of managers who are concerned about GC. For
example, we have found that less than half of our customers by Great Circle
with the idea of deploying their program with it (i.e., only for use as a
reporting tool during development), but approximately 90% end up deploying
with it. I believe these reports are key to helping organizations develop
confidence in and quantify the benefits of GC.
(3) Great Circle is backed by an organization. We have a full time tech
support and services organization and a half dozen people in our SQA
department working full-time on testing and ensuring quality. We can send
engineers to your site to help integrate Great Circle into your
environment, rapidly move Great Circle to new OS releases and test them
(4) We believe we have a number of quality and performance enhancements not
in the Boehm collector. For example, we look for roots in the Windows
message queue, thread local storage, Windows extra words, etc. This greatly
reduces the risk of premature collection. As another example, the native
locks under Windows are very slow, so we use very fast hand-written
assembler locks on single processor machines and spinlocks on MP machines.
Some other enhancements are listed in our ISMM 98 paper. I know the Boehm
collector has also made quality and performance enhancements since our code
forked from it many years ago.
5. With regards to your other question, both the Boehm collector and Great
Circle are highly configurable.
I also want to emphasize that I am not attempting to slam the Boehm
collector, which we have a great debt to and is an excellent collector that
has been used successfully by many individuals and organizations, but
merely to describe where we believe we have been able to provide a
value-add for it and make it easier and more beneficial to use for a wider
variety of organizations.
Whether this creates enough value-add to justify the purchase price is of
course for you to assess. I will simply mention that while Great Circle is
not free, most organizations achieve a rapid ROI and are easily able to
justify the cost.