[gclist] Re: gclist-digest V2 #110
Thu, 22 Jan 1998 10:23:45 -0800
I'm not saying there's no merit in your point, but...
You also need to factor in the risk of inaccurate estimation of the
For example in the GC case, it is tempting to assume uniform
distribution of numerical values, but this is wildly inaccurate.
It is *very* difficult to accurately determine the probabilities on
something like this. The analysis can be much more complex than the code
it would replace!
Another factor to consider is the cost of *debugging* something like
this, if it does arise. I've seen similar reasoning be flawed, and the
resulting problems were *not* easy to track down..
Yes, your complicated code may have a greater than 1 in 10^n chance of
being wrong. However, if it is, you have a much better chance of being
able to test for the defect and fixing it. Once fully tested and fixed,
the probability of a defect drop to zero. The hard part is determining
when you've fully tested it. A good coverage tool, like VisualCoverage
from tracepoint.com is invaluable here!
As a general rule, I think that with good testing techniques, the risk
of bugs can usually be reduced to *below* the risk of mis-estimating the
probabilities, and the cost can be reduced to a reasonable level.
But in cases where the downside risk is small (needing to retry an
operation, say) and the cost of the alternative high, there can be merit
But I wouldn't want my life-support system coded to this standard.
But as to Emacs, I'd have to say that I'd rather risk occasional bloat
than occasional death. The consequences of a bad exact GC are far worse
than the consequences of an overly-conservative GC. With current memory
and VM sizes, Emacs is about 1.5% of my VM and not much more of my RAM
requirements. I think the risk of fatal bugs would outweigh the risk of
inefficient memory usage.
Obviously, this is all opinion, and your mileage may vary.
From: Arch Robison [SMTP:firstname.lastname@example.org]
Sent: Thursday, January 22, 1998 06:34
Subject: %%: [gclist] Re: gclist-digest V2 #110
> >If I were the on the development team, it would not be
> >to decide whether I want to spend more time now debugging a
> >collector where I have control over all aspects of the
> >whether I want to spend much more time later trying to
provide a way
> >to tweak that 1 in 1,000 heap that I have no control over
> >million+ users) that leaks so bad you have to restart every
The "1 in 1,000" raises a question: what is the real
and if known, is it acceptable? On one project, I was faced
implementing something either using a simple technique with a
random 1 in 10^n chance of failure, or a complicated technique
with no (obvious) chance of failure. I had control of n.
I decided on the simple technique because it would result in a
reliable system. Why:
1) Extra time spent on the complicated technique could
be spent more profitably on fixing known bugs that
much more frequently than 1 in 10^n.
2) Given my track record on writing perfect code, it was
that the complicated technique was going to end up
more than 1 in 10^n.
It is true that the number of users and runs per users makes a
And the probabilities are often difficult to figure. But if the
probability is actually quite small relative to other problems
system, then worrying about that is almost surely misplacing
Worrying about absolute perfection is the province of academics.
In the industrial world, we have to evaluate relative risks.
- Arch Robison