David Chase on knobs

[Fergus Henderson]

-----Forwarded message from David Chase <chase at world.std.com>-----

Date: Tue, 22 Sep 1998 11:55:00 -0400
To: gclist at iecc.com
From: David Chase <chase at world.std.com>
Subject: Re: [gclist] The old container problem 

At 01:32 PM 9/22/98 +0100, Nick Barnes wrote:
>Something like this is a good technique if your collector is
>sufficiently flexible to make it possible.  You shouldn't have to have
>an extra collector; in particular note that collection policy (when
>and how often a given part of the heap is collected), promotion policy
>(when and whether parts of the heap are promoted to older
>generations), and maintaining graph invariants are theoretically
>independent of each other, and a good GC will offer the client total
>control over the first two, while having a number of approaches to the
>last.
>
>This isn't rocket science; I suggest that all GC implementors consider
>how best to achieve this sort of flexibility.  Hard-wiring collection
>and promotion policies is as unnecessary and inflexible as hard-wiring
>the number of generations or the maximum heap size.

My knee-jerk reaction to this is "oh dear, more knobs".  I've
become very suspicious of knobs ever since working on compilers
at Sun, where several more experienced people pointed out
that adding one compiler option doubles the testing load, and
more-or-less proved their point by provoking numerous bugs
with randomly chosen compiler flags.  It's a safe bet that
"if it isn't tested, it doesn't work", and adding knobs adds
lots more stuff to test (10 knobs is a 1000x increase in
the bug search space).

I've also observed that, given knobs, the best you can
hope for is that users will ignore them, because if
they don't, odds are good that they'll be set incorrectly.
This leads into the usual experts-versus-amateurs debate
that comes up in the contexts of memory management,
floating point, I/O buffering, C++-versus-simpler
languages, you name it, but in general, the non-experts
outnumber the experts by some large ratio, and economic
forces (especially in the software world) favor the
larger markets.

What, by-the-way, are the performance gains obtained by
this sort of tailored garbage collection?

Sorry to be such a curmudgeon, but I've been burnt by
this before.  I realize that I am taking a bit of a
defeatist attitude towards bugs (i.e., I assume that
they exist, and therefore take defensive measures like
reducing the size of the bug search space for testing,
wouldn't it be nice if we actually proved all this
stuff correct instead) but in practice, people write
buggy code, and almost nobody is willing to pay for
proven-correct code.  (And it sure would be nice if
we could change that by reducing the costs of proving
code correct, or increasing the perceived costs of
buggy code.)

David Chase
NaturalBridge LLC




-----End of forwarded message-----

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.