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

[Guilhem Lavaux]

Helmer Krämer wrote:
> On Sun, 14 Nov 2004 13:26:30 +0100
> Guilhem Lavaux <guilhem at kaffe.org> wrote:
> 
> 
>>Helmer Krämer wrote:
>>
>>>On Sat, 13 Nov 2004 22:01:55 +0100
>>>Mark Wielaard <mark at klomp.org> wrote:
>>>
>>>Hi,
>>>
>>>
>>>
>>>>With this Eclipse 2.1 starts again, but is not completely usable, while
>>>>printing lots of warning messages... (an alternative would be to
>>>>actually implement setSigners() by adopting the GNU Classpath
>>>>ClassLoader implementation).
>>>
>>>
>>>I'll have a look at what needs to be shuffled around to use
>>>GNU Classpath's ClassLoader implementation.
>>>
>>>Regards,
>>>Helmer
>>
>>I remember that when I wanted to import ClassLoader I had to import 
>>Class too and then Double, ... and all other remaining classes of GNU 
>>Classpath.
> 
> 
> Looks like things have changed in the meantime. With the attached
> patch and VMClassLoader implemenation, I can successfully use the
> ClassLoader implementation from GNU classpath. It's not perfect yet,
> as it will not unload native libraries that are no longer in use
> (no clue how often that happens). Any thoughts?
> 

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 think that unloading native libraries may be useful for big 
applications that uses the plugin schemes (e.g. a media player): at one 
time it needs some plugin to load and play a movie then the user choses 
another format which does not need the plugin anymore. As a consequence 
we may unload all classes and libraries linked to it.

> 
>>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). 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.

> 
>>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.

Anyway, thanks for trying to merge ClassLoader in kaffe !

Regards,

Guilhem.