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

[Helmer Krämer]

On Mon, 15 Nov 2004 15:48:14 +0100
Guilhem Lavaux <guilhem at kaffe.org> wrote:

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

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

Good example, wasn't thinking of something like this. 

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

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

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

Regards,
Helmer