On Sun, 14 Nov 2004 13:26:30 +0100 Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
Helmer Krämer wrote:
On Sat, 13 Nov 2004 22:01:55 +0100 Mark Wielaard <[EMAIL PROTECTED]> 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.
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
