[kaffe] Turn exception into warning message for ClassLoader.setSigners()

[Guilhem Lavaux]

>>You're right. You don't need to import anything else if you don't need 
>>to unload native libraries. But if you need this you'll need a way to 
>>mark native library which are unused because the class loader is not 
>>linked anymore to a class. That's where I stopped because either I had 
>>to modify Class*.java (which should not happen for our particular 
>>purpose) either I had to modify the core VM to follow the libraries (I 
>>don't remember how I wanted to do it but maybe using a simple pointer 
>>which is cleared when the class is unloaded so the garbage collector can 
>>finalize NativeLibrary). Maybe you could find an intermediate solution 
>>... :/
> 
> 
> I found out that http://java.sun.com/docs/books/jni/html/design.html not
> only states that native libraries are unloaded when the associated class
> loader is garbage collected (§11.2.5) but also that an UnsatisfiedLinkError
> is thrown when an attempt is made to associate a native library with more
> than one class loader (§11.2.4). 
> 
> So we could alter struct _libHandle in external.c so it contains a pointer
> to the associated class loader instead of a reference count. That way, we
> can easily check whether a native library is associated with a different
> class loader and we can also unload the native libraries when the class
> loader is garbage collected.

Yes we could walk the library handles in destroyClassLoader 
(classPool.c) and look for all handles associated to the class loader 
being destroyed.

> 
>>>>The problem is that the Class implementation of GNU Classpath 
>>>>is totally incompatible with kaffe's current implementation which 
>>>>assumes some things (especially the fields) to make the VM work properly 
>>>>(if not at all).
>>>
>>>
>>>Given that java.lang.Class is merely a wrapper around a VM internal
>>>data structure, I don't see why we should merge java.lang.Class at
>>>all. gcj for example handles java.lang.Class in pretty much the same
>>>way as kaffe does.
>>>
>>
>>Hmm... merging java.lang.Class would diminish our differences with GNU 
>>Classpath and through the VMClass interface it will be easier to follow 
>>the possible evolution of the Classpath structures and/or the Java API.
>>(just a thought).
> 
> 
> Do you have an idea of what changes to the core were required to support
> the new generics stuff?
> 

It looks like that the current classpath (generics-branch) has mostly done
API updates to conform to the new language specification (they have put 
some <?>,
<K> and K around). However there are two exclusive 1.5 methods and 
newInstance()
has changed interface to return the precise object type requested. It 
should not
be too difficult to adapt our own code if the modifications are limited 
to that.

> 
>>BTW, I do not like much the hack at the initialization 
>>pass concerning the class for java.lang.Class: we build a dummy one so 
>>we can load the basic objects to be able to load the real 
>>java.lang.Class. If we had a separate Class structure we would be able 
>>to load the objects directly without considering the possible problems 
>>which would arise from having a dummy class Class in the wilderness.
> 
> 
> We could use a statically allocated vtable for java.lang.Class instances,
> which would enable us to remove the dummyClassClass *duck*.
> 

It looks like we will have to deal specifically with the java.lang.Class 
class again then and I do not like either handling specifically a vtable 
in buildDispatchTable (though it may be less ugly than the current 
situation).

> 
>>>>The only option is to transform all references to 
>>>>Hjava_lang_Class in kaffe into a private internal VM structure and use 
>>>>some object/class resolver to translate this representation into a Java 
>>>>representation whenever we need it externally. BTW, this solution will 
>>>>be necessary when we'll want to fix the remaining problems with the 
>>>>boehm-gc merge.
>>>
>>>
>>>Could you explain what boehm-gc specific problems require a specific
>>>java.lang.Class implementation?
>>>
>>
>>I've spoken to quickly (as always). Actually a compatibility problem 
>>arised when I wanted to merge boehm-gc: if you look at 
>>gcFuncs.c:unloadClass you'll see that kaffe relies a lot on the GC to 
>>know whether a pointer has already been freed or not. Without tracking 
>>the memory structure it will be impossible to do that with the boehm-gc 
>>as it cannot tell me whether the memory has really be freed or not (pure 
>>limitation of the GC for efficiency sake and the developers do not want 
>>to change that). So to make kaffe work with the boehm-gc we'll need to 
>>track more precisely when the memory is freed. I have not yet started to 
>>think about it but I guess some changes in the class structure will be 
>>needed.
> 
> 
> destroyClass is indeed complicated ... If a class becomes unreachable,
> its super classes and all implemented interfaces may simultaneously become
> unreachable, too. This means that destroyClass must not access the super
> class or one of the implemented interfaces, because they might have been
> freed already. At least when freeing the gc_layout of a class, this rule
> is already violated by the current implementation ... 

I was wondering whether we could change our logic into using weak 
references and implicit free by the garbage collector. Suppose that we 
have a weak reference system (available in the boehm-gc and we can 
implement it in our GC) then the GC may update the value of 
clazz->interfaces[j] according to whether the interface has been freed. 
At the same time we could also use non-static allocation for all these 
internal variables which will be automatically freed on demand.

I have already done this for the thread stack for a similar problem when 
threads needed to free their locking variable though the garbage 
collector were holding a lock. Maybe it is completely adaptable.

Regards,

Guilhem.