[gclist] More advice required

Hans Boehm boehm@hoh.engr.sgi.com
Thu, 10 Jun 1999 15:47:30 -0700

On Jun 10,  2:04pm, Charles Fiterman wrote:
> Subject: Re: [gclist] More advice required
> Finalizers are a mistake. Finalizers are doomed.
> Your article makes it clear that finalizers should never be used for
> anything you actually need to have done. If you need it fast, or sure don't
> use finalizers. Only code that can safely be commented out should be put in
> a finalizer. That means the cleanest most reliable, reproducible and
> portable implementation of finalizers is never to run them.
Of course.  And the cleanest, most reliable, reproducible implementation of a
garbage collector is to never run it.  The cleanest, most reliable,
reproducible implementation of an optimizing compiler is to build one that
doesn't optimize.  Given infinite resources, programs will run fine without any
of them.

But if you have finite memory and you need a distributed garbage collector of
any sort, it's awfully hard to get off the ground unless the local collector at
least implements finalization.  There are typically very few uses of
finalization, and they can usually be well hidden, but they tend to be hard to
> People test things. They see a feature like finalizers in Java and write a
> little program to test that it works. Works means always works in the mind
> of the user. They say "I built 1,000,000 finalizable objects and only
> 999,852 of them finalized by my counter therefore your entire Java
> implementation is a buggy piece of shit and I wont trust it for anything.
> Not only that I'll tell my friends." And people who check things out like
> that have friends who really trust their opinions. I don't know the name of
> the language of the future but it will pass their tests.
> A substantial percentage of Java service calls are about unreliable
> finalizers.
That hasn't been my experience.  The ones I did see mostly had to do with the
broken implementation of finalizers, especially in early JDK 1.1.  The
complaints weren't about the documented semantics (which I happen to dislike),
but the fact that the implementation contradicted the language definition, and
the implemented semantics were pretty much unusable.  Conclusion: Software has

Hans-J. Boehm