[gclist] Two conservative collectors

[Boehm, Hans]

[I'm the primary author of the other collector.  Disclaimers similar to
Mike's apply.]

I think Mike presented the trade-off well.  I'd just like to add a couple of
minor
points:

- 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
to
get code contributions to support open source and many more esoteric
platforms.
My own development these days is mostly on Linux, which I believe Geodesic
doesn't
support (??).

- These days, I personally look at win32 only if something looks clearly
broken, fixable,
and nobody else is supplying a fix.  Our collector does not deal explicitly
with
pointers hidden outside the address space visible to the collector.  I think
the
current collector is usable with win32 but, aside from very simple
applications,
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
believe that
works at most partially under win32.  Thus Mike's statement is the correct
answer to the original
question.

I personally also believe that the choice of collector really depends on
your situation.
I was very happy to see Geodesic offer their collector, since it provides an
alternative
for people who need a commercially supported product, with everything that
that entails.

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
more esoteric
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.)

Hans

-----Original Message-----
From: Michael Spertus [mailto:mps@geodesic.com]
Sent: Thursday, November 11, 1999 7:16 AM
To: gclist@iecc.com
Cc: mps@geodesic.com
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" <mtr@igs.net>
>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
>collectors.
>
>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
>http://www.geodesic.com/products/greatcircle.html.
>
>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 
there, etc.

(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.