RE: [kaffe] Problem with JNI...
Hi! hi again, It looks like i forgot to add some code needed by some other changes, can you try the attached patch and see if it works. You'll need to run developers/autogen.sh because theres a configure.in change. Applying the patch seems to have solved the problem.. :) Thanks a lot! sorry about the inconvenience, tim stack //Martin ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] precompiling Klasses.jar
Hi alexander, --- Alexander Popov [EMAIL PROTECTED] wrote: Hi When I try to recompile the java sources I get the following error: [/software/jdk/KAFFE/CVS-current/libraries/javalib]# make Klasses /bin/sh ./rebuildLib Compiling classes ... Classpath: -classpath /software/jdk/KAFFE/CVS-current/libraries/javalib/lib:/darcy/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar javac: /software/jdk/KAFFE/CVS-current/kaffe/kaffe/kaffe-bin -ms32M -mx1024M at.dms.kjc.Main Could not initialize Kaffe. Your rt.jar version is 101.00, but this VM was compiled with version 1.06 The current effective classpath is `.:/software/jdk/KAFFE/CVS-current/libraries/javalib/Klasses.jar:/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar' make: *** [lib/stamp] Error 255 This is the CVS from 05.06.2002 (today)... Am I doing something wrong... Could you check if my fix from http://www.kaffe.org/pipermail/kaffe/2000-August/006784.html applies ? dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] precompiling Klasses.jar
I'll put some dumps in kaffe/kaffevm/baseClasses.c and I'll tell you what exactly happens later today... Dalibor Topic wrote: Hi alexander, --- Alexander Popov [EMAIL PROTECTED] wrote: Hi When I try to recompile the java sources I get the following error: [/software/jdk/KAFFE/CVS-current/libraries/javalib]# make Klasses /bin/sh ./rebuildLib Compiling classes ... Classpath: -classpath /software/jdk/KAFFE/CVS-current/libraries/javalib/lib:/darcy/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar javac: /software/jdk/KAFFE/CVS-current/kaffe/kaffe/kaffe-bin -ms32M -mx1024M at.dms.kjc.Main Could not initialize Kaffe. Your rt.jar version is 101.00, but this VM was compiled with version 1.06 The current effective classpath is `.:/software/jdk/KAFFE/CVS-current/libraries/javalib/Klasses.jar:/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar' make: *** [lib/stamp] Error 255 This is the CVS from 05.06.2002 (today)... Am I doing something wrong... Could you check if my fix from http://www.kaffe.org/pipermail/kaffe/2000-August/006784.html applies ? dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe -- Alexander Popov Team Leader RTOSJVM ProSyst Bulgaria [EMAIL PROTECTED] [EMAIL PROTECTED] mobile: +35987663193 icq: 29207350 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] precompiling Klasses.jar
Sorry Dalibor, my mistake... KAFFE_VERSION in java/lang/Cloneable.java is really the reason and should be changed as follows: int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0; should be replaced with: int KAFFE_VERSION = 1 * 100 + 6 * 1 + 0; I'm attaching a patch for that ( should be applied in KAFFE_SRC/libraries/javalib )... Regards Dalibor Topic wrote: Hi alexander, --- Alexander Popov [EMAIL PROTECTED] wrote: Hi When I try to recompile the java sources I get the following error: [/software/jdk/KAFFE/CVS-current/libraries/javalib]# make Klasses /bin/sh ./rebuildLib Compiling classes ... Classpath: -classpath /software/jdk/KAFFE/CVS-current/libraries/javalib/lib:/darcy/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar javac: /software/jdk/KAFFE/CVS-current/kaffe/kaffe/kaffe-bin -ms32M -mx1024M at.dms.kjc.Main Could not initialize Kaffe. Your rt.jar version is 101.00, but this VM was compiled with version 1.06 The current effective classpath is `.:/software/jdk/KAFFE/CVS-current/libraries/javalib/Klasses.jar:/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar' make: *** [lib/stamp] Error 255 This is the CVS from 05.06.2002 (today)... Am I doing something wrong... Could you check if my fix from http://www.kaffe.org/pipermail/kaffe/2000-August/006784.html applies ? dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe -- Alexander Popov Team Leader RTOSJVM ProSyst Bulgaria [EMAIL PROTECTED] [EMAIL PROTECTED] mobile: +35987663193 icq: 29207350 --- java/lang/Cloneable.javaWed Jun 5 14:23:49 2002 +++ java/lang/Cloneable.javaWed Jun 5 14:24:01 2002 @@ -20,3 +20,3 @@ */ -int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0; +int KAFFE_VERSION = 1 * 100 + 6 * 1 + 0; }
[kaffe] Familiar iPAQ/ARM Linux success + comments
Using latest CVS code of the intended release branch, I managed to cross-compile the desktop Kaffe for Familiar 0.5.2 release... Using the standard toolchain for now. Unfortunately Kaffe's build-scripts aren't very cross-compile considerate right now, so this took mroe than little of testing and hacking. Most notably libtool does its usual forced-lib-path annoyance. Configured with: export PATH=/skiff-2.96/local/bin:/skiff-2.96/local/arm-linux/bin:$PATH ../kaffe/configure --with-x --x-includes=/skiff-2.96/local/arm-linux/include/X11 --x-libraries=/skiff-2.96/local/arm-linux/lib/X11 --with-libraries=/skiff-2.96/local/arm-linux/lib --with-includes=/skiff-2.96/local/arm-linux/include --prefix=/usr/kaffe arm-linux Then need to set up sys_lib_search_path_spec for libtool, or just edit libtool to substitute the paths. It's perhaps also worth mentioning that the default Handhelds.org toolchain can't anymore handle the binary format in many newer ARM libraries, but this may not be a problem for dynamic linking. In any case the toolchain eneds to be augmented with some supplementary libs for jpeg, png, zlib etc. if somebody does try to reproduce this. It builds with jit by default. Finally, copying the whole resulting installation directory to iPAQ, and running it on XSmiles slowly gets through the moves up and until after the parsing, layout and display should be done (but display update hangs at some point) and then breaks with: [Debug] *** Fetcher thread exiting, time: 56.54 secs. Dumping live threads: `AWT-EventQueue-0' tid 0xd84010, status SUSPENDED flags DONTSTOP blocked@0x1a91c8 (0xd84010-|) `gc' tid 0x219010, status SUSPENDED flags DONTSTOP blocked@0x208498 (0x219010-|) `finaliser' tid 0x210010, status SUSPENDED flags DONTSTOP blocked@0x208450 (0x210010-|) Deadlock: all threads blocked on internal events Aborted Going to be running the test-suite and otherwise trying to track that down when I can, but thought I'd report that for the most part it seems to be working for me. Cross-compiling should be made easier and more intuitive, and port jit3 for ARM over from PL, though. -Jukka Santala ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] java.lang.String.valueOf( Obj ) buggy?
I'm constantly getting NullPointerException when trying to call java.lang.String.valueOf(Object obj)... I'm using the current CVS and linux/x86 (glibc-2.2.4/linux-2.4.16) Any hints? Regards, -- Alexander Popov Team Leader RTOSJVM ProSyst Bulgaria [EMAIL PROTECTED] [EMAIL PROTECTED] mobile: +35987663193 icq: 29207350 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] MySQL JDBC drvers
Has anyone here been successful with Kaffe communicating to MySQL via JDBC? Any reccomended drivers? Thanks, Chris ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] precompiling Klasses.jar
Oops. My fault. I'll look at it once more... Cheers, - Jim On Wed, 2002-06-05 at 06:37, Alexander Popov wrote: Sorry Dalibor, my mistake... KAFFE_VERSION in java/lang/Cloneable.java is really the reason and should be changed as follows: int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0; should be replaced with: int KAFFE_VERSION = 1 * 100 + 6 * 1 + 0; I'm attaching a patch for that ( should be applied in KAFFE_SRC/libraries/javalib )... Regards Dalibor Topic wrote: Hi alexander, --- Alexander Popov [EMAIL PROTECTED] wrote: Hi When I try to recompile the java sources I get the following error: [/software/jdk/KAFFE/CVS-current/libraries/javalib]# make Klasses /bin/sh ./rebuildLib Compiling classes ... Classpath: -classpath /software/jdk/KAFFE/CVS-current/libraries/javalib/lib:/darcy/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar javac: /software/jdk/KAFFE/CVS-current/kaffe/kaffe/kaffe-bin -ms32M -mx1024M at.dms.kjc.Main Could not initialize Kaffe. Your rt.jar version is 101.00, but this VM was compiled with version 1.06 The current effective classpath is `.:/software/jdk/KAFFE/CVS-current/libraries/javalib/Klasses.jar:/software/jdk/KAFFE/CVS-current/libraries/javalib/kjc.jar' make: *** [lib/stamp] Error 255 This is the CVS from 05.06.2002 (today)... Am I doing something wrong... Could you check if my fix from http://www.kaffe.org/pipermail/kaffe/2000-August/006784.html applies ? dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe -- Alexander Popov Team Leader RTOSJVM ProSyst Bulgaria [EMAIL PROTECTED] [EMAIL PROTECTED] mobile: +35987663193 icq: 29207350 --- java/lang/Cloneable.java Wed Jun 5 14:23:49 2002 +++ java/lang/Cloneable.java Wed Jun 5 14:24:01 2002 @@ -20,3 +20,3 @@ */ -int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0; +int KAFFE_VERSION = 1 * 100 + 6 * 1 + 0; } ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Godmar wrote: The string with the dead char array should at this point already be scheduled for destruction. So one possible way would be to take the gc_lock and block on intern() if the mustfree is not empty. That seems like it might work... A quick hack would be to destroy all strings first then the rest, this way a string would always be destroyed before its char[] object. Hmmm... actually, we could pretty easily have two mustfree lists. One for objects with destroy methods, and one for all the other objects. That would accomplish the ordering without too much magic required in finishGC. Its not pretty, though. Given that we know what's happening, I've been surprised by the fact that I can't come up with a test case that causes this problem on existing Kaffe, or other engines. I'd have more faith in a fix for this problem if there was a test case that caused the problem on more installations of Kaffe than just the interp-debug-with-per-JNI-method-exceptions-patch Let me know if you can come up with a test case that tickles this problem -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Mean people suck. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/06/05 12:27:23 Modified files: libraries/javalib: Klasses.jar Log message: Regen Klasses.jar (to take care of java.lang.Cloneable version number change ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Hmmm... actually, we could pretty easily have two mustfree lists. One for objects with destroy methods, and one for all the other objects. That would accomplish the ordering without too much magic required in finishGC. Its not pretty, though. Not excessively so. This might potentially also cover cases that are potentially similar (ClassLoader/Class related.). - Godmar ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Perhaps the intern'd string table should be walked, but only the char[] objects referenced from it should be marked (not the Strings). You could mark objects meant to be destroy()ed like objects meant to be finalized... I don't think this would work because the char[] could be gone before the String object is moved to the finalizer list... The only thing keeping the char[] alive is the live String reference. Right, marking the string implies that it would recursively mark the array. With some shuffling of the lists you could probably automagically implement the dependencies here, anything added to the grey/black list at this point would be swept after these objects. Also, I suppose you could just gc_add_ref() the array on intern and gc_rm_ref() on unintern. I don't think the unintern would ever get called because the String would always have a reference. This would solve the problem, but fill the string table with unused intern'd strings. :) er, gc_add_ref() _the array_ (i.e. gc_add_ref(string-value);), not the string object, thats what you proposed! :) Can we just drop the string table lock and use the gc_lock instead? They seem to be mingling quite a bit. Would this also solve the nastiness with the stringAlloc()/stringFree() functions having to unlock the stringLock. I think there was some effort to split these two locks in the past... there must have been a good reason for that I don't know if the increased contention for the lock would make any difference (or the potential recursive acquires) bah, the log gives no clues... -Pat tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
I think there was some effort to split these two locks in the past... there must have been a good reason for that I don't know if the increased contention for the lock would make any difference (or the potential recursive acquires) Not that it would be very relevant in Kaffe's dog-slow silly gc system, but I think that's the main reason. One big master lock would certainly solve the problem. Another possible less intrusive idea: Why not just hold the string intern lock while working off the must-free list. Take it before working off the list, release it afterwards. This does not lead to deadlock, because one invariant we already have to guarantee is that no thread holding the intern lock will ever try to get the gc_lock. (by virtue of stringAlloc/stringFree.) More generally, no thread must try to allocate memory while holding any lock that is also accessed during a destroy() method call. - Godmar ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Another possible less intrusive idea: Why not just hold the string intern lock while working off the must-free list. Take it before working off the list, release it afterwards. I think we run into the same problem as before though, we can't take the lock before RESUMEWORLD() because it could deadlock and we can't take it after because of the race condition. In fact, if someone had the lock and was looking up a string before the gc calls STOPWORLD() we'd lose again. U1 hashFindSlot(FooBar); - thread switch just before it finds it, otherwise the collector would see the reference on the thread stack. GC STOPWORLD(); GC add FooBar to must free GC RESUMEWORLD(); GC lockStaticMutex(stringLock); - GC blocks waiting for U1 to finish U1 finds bogus FooBar Now, the reason i brought up weak references was that they could behave similarly: weak ref (i probably way off on how this is supposed to work): STOPWORLD(); weak ref (WR) placed on post processing list WR.disable() nulls out the reference if it is white some other conditions (e.g. low mem) RESUMEWORLD(); WR.destroy() puts the object on the ReferenceQueue (need to do it outside the RESUMEWORLD(); because someone can have the queue locked). interned string: STOPWORLD(); interned string (IS) is white IS.disable() nulls out the char[], preventing any matches. As stated above, if the thread already found it, the collector would've traced it. RESUMEWORLD(); IS.destroy() removes the string from the table. this seems to work, and theres no locking problem, i think... - Godmar tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
