[kaffe] Weak references/Class destruction

[Guilhem Lavaux]

Hi,

I've implemented the idea. It looks like working fine though instanceof does
not like some particular cases with the new implementation: CLASS_IS_ARRAY,
CLASS_IS_INTERFACE are normal special cases as they do not have any 
implementors
and so we cannot find their interface ancestors. But it looks like there 
are some others
when looking at the testcases results. I have still not found them as 
I'm trying to
fix a deadlock in GCTest.

Also, I think I can remove safely the atomic exchange in 
soft_fixup_trampoline now and only put a "*where = ret".

Anyway here is the new patch.

Regards,

Guilhem Lavaux.

Helmer Krämer wrote:

>Guilhem Lavaux <guilhem at kaffe.org> wrote:
>
>  
>
>>Helmer Krämer wrote:
>>
>>    
>>
>>>Guilhem Lavaux <guilhem at kaffe.org> 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?
>>>
>>> 
>>>
>>>      
>>>
>>Completely right ! :)
>>    
>>
>
>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).
>
>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.
>
>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.
>
>Having this sort of table would probably also allow us to easily
>implement instanceof_interface in constant time.
>
>Regards,
>Helmer
>
>_______________________________________________
>kaffe mailing list
>kaffe at kaffe.org
>http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
>
>  
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: class_patch
Url: http://kaffe.org/pipermail/kaffe/attachments/20041223/7831977f/attachment-0002.txt