[kaffe] Weak references/Class destruction

[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).
>
>  
>
Hmm... I must have removed it in a previous implementation as gc_layout 
was also
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.