Re: class gc & future gc interface

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Mon Jan 04 1999 - 15:05:41 EST


 Archie,

We broke Kiev sometime between Dec 18 and Dec 24.
I think it's after Jason's merge.

Reproducing the failure Maxim reported is easy:
Simply do a
setenv CLASSPATH kiev008_g.jar
kaffe kiev.Main

Happens both with intrp/jit, mmap/hash, and even with
-vmdebug NOGC. Try -vmdebug GCDIAG to find an assertion faster.

It looks like a wild write. Btw, do you know how to use hardware
watchpoints in Linux's gdb?

Now to answer your mail:

>
> I want to try to understand what you're doing, but I'm not
> completely clear on it..
>
> > In my opinion, there was no way around destructors for class objects;
> > the existing finalizer mechanism simply would not have guaranteed that
> > class objects survive all instances of the class.
>
> One thing I don't understand is how could an object outlive the
> Class object of which it is an instance? Doesn't every object
> contain a pointer to it's Class object (at least implicitly)?

I wasn't very clear.
Suppose x is an object of class X. Suppose further we tried to use our
normal finalizers. At some point, both x and X.class become eligible
for finalization. They're both in the finalize list.

Clearly, it's wrong to finalize X.class first because that would render
the class X unusable, and x.finalize will blow up.
So it fails right there because we do not have any ordering in our finalizer
lists.

Suppose we had what's called a topological ordering: since x refers to
X.class, it is finalized first. Then, it is possible that x reattaches
itself and survives. In this case, the finalization of the class object
must be canceled. This would also have to be implemented.

Basically, I just felt that doing the equivalent of C++ delete was
the easiest way to go.

>
> Also, is the root of the problem here that when you finalize something,
> it may come back to life? And so you need a separate 'destructor'
> that's called when you know for sure that the object is going away?

Yes.

>
> In other words, my assumption was that a Class object would have
> lots of utf8const's in it. When the object was finalized, we would
> simply need to release all of those utf8consts.. but you're saying
> that the destructor would do this instead.. presumably because
> finalization is not really final?
>

Well, Java object finalization isn't. The finalize lists in the collector
implement just that, so it's not suitable for class object destruction.

        - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:28 EDT