Helmer Kr�mer wrote:
Hmm... I must have removed it in a previous implementation as gc_layout was alsoGuilhem Lavaux <[EMAIL PROTECTED]> wrote:
Helmer Kr�mer wrote:
Completely right ! :)Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
Hi,
Here is a patch which changes the way the classes are destroyed and implements
weak references for boehm-gc and kaffe-gc. This fixes class concurrent
destruction issues which was bugging boehm-gc (and maybe also kaffe-gc) and
should insure that we do not access already freed memory.
If I remember it correctly, the problems with boehm-gc and garbage collecting classes are:
a) Suppose class A is the only class implementing interface I. If A becomes unreachable, so does I. In this case however, there's no guarantee that C is destroyed before I. This means that destroyClass has to deal with the fact that I might already have been destroyed when C is destroyed. This gets complicated for the implementors table and the interface dispatch tables because destroyClass has to remove C from some of the structures stored inside I.
b) Same thing when a class A and its super class A' become unreachable at the same time. In this case, some of the pointers stored in the vtable (and interface dispatch table) may no longer be valid because A' was already destroyed.
The solution for a) is to use weak references.
The solution for b) is to use allocation types that are automatically freed by the gc for everything that might be stored in a vtable (or interface dispatch table).
Is this correct so far?
Cool :)
The solution for Problem b looks fine to me too, although I'm missing freeing the gc_layout bitmap (I might have overlooked that, though).
depending on superclass and forgotten to bring it back.
So either I put it back explicitly, either I use the weak reference on superclass
(which I've installed in this implementation) either gc_layout should be garbage collected
(as I was thinking to do because of the KGC_markObject(gc_layout)). In that case I might
create a new GC type.
Thanks.
For Problem a, I'm going to describe an alternative solution that doesn't need weak references, mainly to get some arguments for the different implementations into the mail archives (the implementation of weak references itself seems ok to me and should go in so we can have support for java.lang.ref later on).
The itable2dtable of a class is just one large chunk of memory
containing all dispatch tables of all interfaces. If we stored
the Hjava_lang_Class* of the class owning the itable2dtable at
the beginning of the table, we could use KGC_getObjectBase to get
the class implementing the interfaces (sort of like its done in
stackTrace.c to retrieve the java method of a given pc). All we
need is a pointer somewhere into the itable2dtable chunk.
Right. And also will remove the 'short' type which is always a risk. :)
If we further modified the implementors table to store a pointer into the itable2dtable instead of an index (soft_lookupinterfacemethod would look like ncode = ifclass->implementors[cls->impl_idx][idx+1]), we should get all the information we need to implement destroyClass without relaying on the gc to keep track of destroyed objects:
A class can still remove itself from the implemented interfaces. An interface can remove itself from the implementing classes by traversing the implementors table and using KGC_getObjectBase to get the implementing class. Since a class is removed from the implementors table when it is destroyed, we can assume that the pointers stored in the implementors table are valid when an interface is destroyed.
Ok. So the situation becomes symmetric: the intterface knows the implementors so it can modify them if it is freed, and the implementors knows the interfaces too so they can update them if the class is freed.
Having this sort of table would probably also allow us to easily implement instanceof_interface in constant time.
Which is also better. Instanceof is a really used call in java.:)
Ok. I'm going to modify the patch accordingly.
Regards,
Guilhem Lavaux.
_______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
