From: Godmar Back (gback@cs.utah.edu)
Date: Fri Dec 11 1998 - 15:25:22 EST
>
> On Dec 11, 1998, Godmar Back <gback@cs.utah.edu> wrote:
>
> >>
> >> On Dec 11, 1998, Godmar Back <gback@cs.utah.edu> wrote:
> >>
> >> >> optimize empty finalizers away, step 1.
> >>
> >> > Btw, this had brought down the library compile time from 28 to 26 seconds
> >> > again. (Still my unofficial performance measure).
> >>
> >> Great!
> >>
> >> > The next step, of course, is to avoid calls to finalizeObject at all.
> >>
> >> Do you really think this will make so much difference?
>
> > Well, it will make some difference. I think the soft_instanceof calls
> > to check for thread classes add up.
>
> Wouldn't it be simpler to arrange that Thread.finalize() calls a
> native method (or is itself a native method) that does whatever we
> need to finalize a Thread? This would obviate the need for a second
> kind of test.
>
Nope. Relying on Thread.finalize is impossible because Thread is
not a final class and a subclass finalizer may not call super.finalize.
We fixed that a while ago. Thread still has a method declaration
`finalize0' in it that bears witness to this attempt.
> Of course, someone might fail to call super.finalize() in a subclass
> of Thread, but then it's not our fault. Should we care about this
> case?
See above. (I typed before I read what you said)
I think we must care or else we can't free the thread's stack just
because someone overrides finalize and doesn't call super.finalize.
That would be unacceptable, IMO.
Btw, String is a final class so the case is different there.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:12 EDT