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.