Re: [kaffe] Kaffe CVS: kaffe hkraemer
* libraries/javalib/java/lang/Throwable.java: Replaced with Classpath version. * libraries/javalib/java/lang/VMThrowable.java: New class. * libraries/javalib/bootstrap.classlist: Add VMThrowable. * libraries/javalib/essential.files: Add StackTaceElement and VMThrowable. * libraries/javalib/Klasses.jar.bootstrap: Regenerated. Helmer, could you add VMThrowable.java ? it is missing in the repository. Thanks. Cheers, Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe hkraemer
On Mon, 28 Jul 2003 10:10:19 +0200 Guilhem Lavaux [EMAIL PROTECTED] wrote: * libraries/javalib/java/lang/Throwable.java: Replaced with Classpath version. * libraries/javalib/java/lang/VMThrowable.java: New class. * libraries/javalib/bootstrap.classlist: Add VMThrowable. * libraries/javalib/essential.files: Add StackTaceElement and VMThrowable. * libraries/javalib/Klasses.jar.bootstrap: Regenerated. Helmer, could you add VMThrowable.java ? it is missing in the repository. Thanks. Done. Sorry, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe hkraemer
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: hkraemer03/07/28 01:09:48 Added files: libraries/javalib/java/lang: VMThrowable.java Log message: file I forgot :( ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problems with UnsatisfiedLinkError
Hi ?, Cray Kaffe wrote: Hi, I am porting Kaffe on Cray SV1. you seem to be part of a large team ;) when I run: ./kaffe HelloWorld I get following errors: Call: java/lang/Class.forName(Ljava/lang/String;)Ljava/lang/Class; Call: java/lang/Object.getClass()Ljava/lang/Class;. Call to native java/lang/Object.getClass()Ljava/lang/Class;. Call: java/lang/UnsatisfiedLinkError.init(Ljava/lang/String;)V. Call: java/lang/LinkageError.init(Ljava/lang/String;)V. Call: java/lang/Error.init(Ljava/lang/String;)V problem seems related to searching Shared Library. Can anyone suggest a way out ? for a fresh port, I'd recommend starting with the static build. Shared library support usually depends on how well libtool supports it under your platform. Take a look at http://www.kaffe.org/cgi-bin/viewcvs.cgi/*checkout*/kaffe/FAQ/FAQ.libtool?rev=HEAD for more information on available options. I'd recommend --with-staticvm --with-staticlib for a start. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe guilhem
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: guilhem 03/07/28 02:39:09 Modified files: . : ChangeLog kaffe/kaffevm : baseClasses.h stackTrace.c thread.c kaffe/kaffevm/systems/unix-pthreads: lock-impl.h thread-internal.h libraries/javalib: bootstrap.classlist libraries/javalib/java/lang: Throwable.java libraries/javalib/java/text: DecimalFormat.java test/regression: TestMessageFormat.java Log message: Fixes to make unix-pthreads compile with JVMPI (but lots of not implemented features). * kaffe/kaffevm/unix-pthreads/lock-impl.h, kaffe/kaffevm/unix-pthreads/thread-impl.h: (jcondvar_broadcast) implemented (THREAD_*) added to ensure the compatibility with jthreads (jthread_suspend, jthread_resume, jthread_from_data, jthread_get_usage, jthread_is_interrupted, jthread_on_mutex, jthread_on_condvar) added dummy functions. Various fixes. * libraries/javalib/bootstrap.classlist: Added missing classes java.text.MessageFormat and URLClassLoader. * libraries/javalib/java/text/DecimalFormat.java: Fixed parsing of the number pattern: missing exponential format. * kaffe/kaffvm/baseClasses.h: Added external references to VMThrowable and StackTraceElement. * kaffe/kaffevm/stackTrace.c: added include file java_lang_StackTraceElement.h. * libraries/javalib/java/lang/Throwable.java: copied from GNU/Classpath. * test/regression/TestMessageFormat.java: Hardened the test case. * libraries/javalib/Klasses.jar: regenerated. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] config.frag files for NetBSD
Hi,
Thanks for the official support of crosstools in the latest NetBSD,
I tried to compile all Kaffe configurations available for NetBSD
(alpha, arm, m68k, mips, powerpc, sparc).
Attached patch deleted unneeded defs in config.frag files for these
configurations. I think similar mods can be applied to all other
platforms.
The mods can be devided into four types
1. Delete 'Khost_cpu' and 'Khost_os' defined in some files.
2. 'ac_cv_sizeof_int' etc. are now properly handled by 'configure'
even for cross compiling.
3. 'ac_cv_c_char_unsigned' is now set to 'no', when cross compiling.
4. 'CFLAGS' is now used only to append mandatory settings for the port.
Typical way of cross compiling is done by
../kaffe-1.1.0/configure --host=m68k--netbsdelf --enable-debug \\
--with-staticbin --with-staticlib --with-staticvm \\
--with-threads=unix-jthreads --without-x --without-sound \\
--with-engine=intrp \\
--with-rt-jar=$PWD/../kaffe-1.1.0/libraries/javalib/rt-precompiled.jar
At least for alpha, arm, m68k, powerpc, sparc, this new config.frag
works fine to make 'kaffe-bin', and with slight modification, mips is
also ok but it's another topic.
Is this mod applicable?
Kiyo
-
diff -Naur kaffe-1.1.0.orig/config/alpha/netbsd1/config.frag
kaffe-1.1.0/config/alpha/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/alpha/netbsd1/config.frag Wed May 21 17:40:41 2003
+++ kaffe-1.1.0/config/alpha/netbsd1/config.fragMon Jul 28 18:12:40 2003
@@ -1,6 +1,8 @@
#
# Alpha/Netbsd1 configuration
#
-Khost_cpu=alpha
-Khost_os=netbsd1
CFLAGS=$CFLAGS -mieee
+
+if [ $cross_compiling = yes ]; then
+ ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
+fi
diff -Naur kaffe-1.1.0.orig/config/arm/netbsd1/config.frag
kaffe-1.1.0/config/arm/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/arm/netbsd1/config.frag Sun Oct 17 05:52:40 1999
+++ kaffe-1.1.0/config/arm/netbsd1/config.frag Mon Jul 28 18:12:43 2003
@@ -2,3 +2,7 @@
# Arm/Netbsd1 configuration
#
vm_dynamic_library=no
+
+if [ $cross_compiling = yes ]; then
+ ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
+fi
diff -Naur kaffe-1.1.0.orig/config/i386/netbsd1/config.frag
kaffe-1.1.0/config/i386/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/i386/netbsd1/config.fragSat Dec 18 14:09:32 1999
+++ kaffe-1.1.0/config/i386/netbsd1/config.frag Mon Jul 28 18:11:53 2003
@@ -1,5 +1,6 @@
#
# i386/Netbsd1 configuration
#
-Khost_cpu=i386
-Khost_os=netbsd1
+if [ $cross_compiling = yes ]; then
+ ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
+fi
diff -Naur kaffe-1.1.0.orig/config/m68k/netbsd1/config.frag
kaffe-1.1.0/config/m68k/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/m68k/netbsd1/config.fragSat Dec 18 14:09:35 1999
+++ kaffe-1.1.0/config/m68k/netbsd1/config.frag Mon Jul 28 18:12:49 2003
@@ -1,18 +1,8 @@
#
# m68k/Netbsd1 configuration.
#
-Khost_cpu=m68k
-Khost_os=netbsd1
-CFLAGS=-g -Wall -Wstrict-prototypes
+CFLAGS=$CFLAGS -fno-omit-frame-pointer
+
if [ $cross_compiling = yes ]; then
-# if we use cross environment, following values may not be detected.
- ac_cv_alignmentof_voidp=${ac_cv_alignmentof_voidp='2'}
- ac_cv_c_bigendian=${ac_cv_c_bigendian='yes'}
- ac_cv_sizeof___int64=${ac_cv_sizeof___int64='0'}
- ac_cv_sizeof_int=${ac_cv_sizeof_int='4'}
- ac_cv_sizeof_long=${ac_cv_sizeof_long='4'}
- ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long='8'}
- ac_cv_sizeof_short=${ac_cv_sizeof_short='2'}
- ac_cv_sizeof_voidp=${ac_cv_sizeof_voidp='4'}
+ ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
fi
-
diff -Naur kaffe-1.1.0.orig/config/mips/netbsd1/config.frag
kaffe-1.1.0/config/mips/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/mips/netbsd1/config.fragSat Dec 18 14:09:36 1999
+++ kaffe-1.1.0/config/mips/netbsd1/config.frag Mon Jul 28 18:12:52 2003
@@ -1,5 +1,8 @@
#
# Mips/Netbsd configuration.
#
-Khost_cpu=mips
-Khost_os=netbsd1
+CFLAGS=$CFLAGS -fno-omit-frame-pointer
+
+if [ $cross_compiling = yes ]; then
+ ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
+fi
diff -Naur kaffe-1.1.0.orig/config/powerpc/netbsd1/config.frag
kaffe-1.1.0/config/powerpc/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/powerpc/netbsd1/config.frag Tue Aug 28 23:58:46 2001
+++ kaffe-1.1.0/config/powerpc/netbsd1/config.frag Mon Jul 28 18:12:32 2003
@@ -1,8 +1,11 @@
#
# PowerPC/NetBSD configuration
#
-Khost_cpu=powerpc
-Khost_os=netbsd1
+CFLAGS=$CFLAGS -fsigned-char
+
+if [ $cross_compiling = yes ]; then
+ ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
+fi
if test $with_setjmp = glibc; then
# Use setjmp()/longjmp() from glibc-2.2.2
@@ -11,5 +14,3 @@
# Use sigsetjmp()/siglongjmp()
CPPFLAGS=$CPPFLAGS -DJTHREAD_USE_SIGSETJMP
fi
-
-CFLAGS=$CFLAGS -fsigned-char
diff -Naur kaffe-1.1.0.orig/config/sparc/netbsd1/config.frag
kaffe-1.1.0/config/sparc/netbsd1/config.frag
--- kaffe-1.1.0.orig/config/sparc/netbsd1/config.frag Sat Dec 18
Re: [kaffe] config.frag files for NetBSD
Kiyo Inaba wrote: Hi, Thanks for the official support of crosstools in the latest NetBSD, I tried to compile all Kaffe configurations available for NetBSD (alpha, arm, m68k, mips, powerpc, sparc). Attached patch deleted unneeded defs in config.frag files for these configurations. I think similar mods can be applied to all other platforms. looks good to me. since you've tested it, please check it in. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] using kaffe instead of JDK to build open office
Hi, on LinuxTag, I got in touch with OpenOffice developers, and had an interesting conversation off-list with Chris Halls, a debian developer, who is trying to use kaffe instead of JDK to build OpenOffice. According to debian policies, as long as OpenOffice can't be built using free tools exclusively, it can't be moved into the free software section. Getting kaffe to build openoffice would be very nice. It would also be appreciated by OpenOffice developers on platforms without a port of a recent JDK, like BeOS, from what I've heard on LinuxTag. Chris' sent me an e-mail about kaffe and openoffice last week, part of which I'd like to quote here: ---quote-- So I'd like to have some pointers as to where to start getting in touch with the developers from 'fringe' OpenOffice platforms, as well as to a document describing the OpenOffice's requirements for a Java environment in more detail. Finally, pointers to appropriate mailing lists would be great. There is some work going on. Have a look at Issue 16252: http://www.openoffice.org/issues/show_bug.cgi?id=16252 The JDK is used in OOo in several different ways: - Some tools needed to build essential parts of OOo are in Java. The projects that I know of that needs these are officecfg and readlicense_oo. The patch I made for IZ16252 makes it possible to build these using Kaffe. - Support for various optional features of OOo, using the UNO Java bridge which allows components to be written in Java. I have not looked at this yet. - Some C++ projects need JNI, such as jvmaccess. These modules do not compile with Kaffe because bridges/source/jni_uno/jni_base.h needs JNIEnv_::ExceptionCheck() from jni.h. I have been concentrating so far on getting OOo built without Java support, which only needs the build tools. Theoretically, it should be possible to do this without patches just by unsetting SOLAR_JAVA, but it hasn't been tested since before 1.1 and needs various changes. I have several changes on my disk, which I need to turn into IZ patches when I have time. I have amnaged to build about 70% of OOo so far with Kaffe as JDK and SOLAR_JAVA unset. ---quote-- As a quick heads up to kaffe developers: that means we're about 70% there with kaffe 1.1.0. Latest kaffe from CVS also includes JNIEnv_::ExceptionCheck() (thanks to Mark Wielaard's work on getting java-gnome and snark to run on kaffe), so this should help building the C++ projects that need JNI as well. Since we are scheduled to release the next developer release of kaffe, 1.1.1, next weekend, it will be interesting to see how well that release fares for open office builds. And of course, it would be nice to see Chris' patches going in into OpenOffice, unless they have been applied already. I hope we can get some input from OpenOffice developers on what needs to be fixed in kaffe to allow OOo to build. And who knows, we may even exchange some contributions ;) cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hi Tim, After looking into backporting the JanosVM design, I've decided to leave the class loading system largely alone, with the exception that loadClass will have a new parameter that allows you to specify to what target state a class should be loaded until. The new method is called loadClassToState, and loadClass simply forwards a call to loadClassToState with the default target state. The reason for this is that, during verification, if I really need to load a class, I don't want to link it (that can cause circular dependency problems when loading on the same thread), but only get it to the point where I can see its superclass. If you can see any problems with this, let me know. Instead of touching the rest of the loader, I'm dealing with lots of string comparrisons of names and type signatures in the verifier. Thus if I don't need to load a class but know its name, I treat it's name as its type. Lots of casts and shit, a little messy, but it gets the job done without messing with the loader. Cheers, Rob I'm just not convinced you need to mess with class loading to do this. There is a lot of complexity and subtlety in loading and I would really like to avoid touching it without good cause. I'm not really talking about any serious modification to class loading. Every change to the loader is serious ;) All that would happen is that the memory allocation of the Hjava_lang_Class instance would happen earlier, allowing me to have a pointer to the class for type checking without loading the actual class. Again, right now the memory allocation is tied to the actual class loading. Everything else would remain as is. One example I can think of is that it might conflict with error handling. At the moment, the loader allows you to reload classes that fail early on, which mimics the behavior of jdk 1.3.1. This might not work anymore if the class pointer has to be stable and can't be replaced for a failed class. There might be other semantic changes that crop up as well... Basically, the only thing I know is that the lookup.c path is much less treacherous than trying to change the loader. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Erorr in building CVS
Well then I dont feel so stupid and that would make sense On Monday 28 July 2003 11:03 am, Timothy Stack wrote: Okay here goes. Maybe I am completly missing something here that I should know. If so I am sorry. But here is whats happening The repository is broken at the moment, should be fixed in a bit by helmer (hint hint, nudge nudge ;) tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Erorr in building CVS
Timothy Stack wrote: Okay here goes. Maybe I am completly missing something here that I should know. If so I am sorry. But here is whats happening The repository is broken at the moment, should be fixed in a bit by helmer (hint hint, nudge nudge ;) Tim, could you check in the attached patch (works for me). It adds the missing StackTraceElement ro essential.files. cheers, dalibor topic Index: libraries/javalib/essential.files === RCS file: /cvs/kaffe/kaffe/libraries/javalib/essential.files,v retrieving revision 1.14 diff -u -r1.14 essential.files --- libraries/javalib/essential.files 27 Jul 2003 21:42:24 - 1.14 +++ libraries/javalib/essential.files 28 Jul 2003 14:58:46 - @@ -141,6 +141,7 @@ java/lang/SecurityManager.java java/lang/Short.java java/lang/StackOverflowError.java +java/lang/StackTraceElement.java java/lang/String.java java/lang/StringBuffer.java java/lang/StringIndexOutOfBoundsException.java @@ -309,4 +310,4 @@ kaffe/util/Ptr.java kaffe/util/UNIXTimeZone.java kaffe/util/UTF8.java -kaffe/util/zip/SwitchInflater.java \ No newline at end of file +kaffe/util/zip/SwitchInflater.java
Re: [kaffe] Erorr in building CVS
Thanks I applied that patch and worked right away so it works for me too On Monday 28 July 2003 11:10 am, Dalibor Topic wrote: Timothy Stack wrote: Okay here goes. Maybe I am completly missing something here that I should know. If so I am sorry. But here is whats happening The repository is broken at the moment, should be fixed in a bit by helmer (hint hint, nudge nudge ;) Tim, could you check in the attached patch (works for me). It adds the missing StackTraceElement ro essential.files. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failures
Timothy Stack wrote: hi, hi, Thanks, I didn't notice we had different failures. ops, I didn't look close enough, the intrp ones are my fault... I need to fix it so jvmpi works right. should be fixed by attached patch. cheers, dalibor topic thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe-extras
On Mon, 28 Jul 2003 08:44:47 +0200 Dalibor Topic [EMAIL PROTECTED] wrote: Basically, it works similar to how a ports style system works. I'm just checking in scripts to download tar and zip files, patch them, and build stuff. There are two basic scripts. The first one, bootstrap-kaffe+ant.sh just downloads the sources for kaffe and ant, and builds them. I've noticed that it uses kaffe 1.1.0. I think that for fixing/finding bugs and evaluating actual current status with ant and other tools, using kaffe from CVS head would be a better option. On the other hand, it's good to try to use what we've released to help gauge where we're at. It'll help motivate us to do better releases. Is there a simple way to use CVS head as the java environment? Just publish a snapshot make dist tarball somewhere and adapt the scripts. Or just skip the bootstrap step and use a kaffe compiled somewhere else on your system. I found a few bugs in Kaffe 1.1.0 with the kaffe-extras script. If those still exist in the CVS version, it would be nice to fix them in time for 1.1.1 (next Sunday). Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe stack
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: stack 03/07/28 09:03:43 Modified files: . : ChangeLog kaffe/kaffevm/intrp: stackTrace-impl.h libraries/clib/management: JIT.c libraries/javalib/kaffe/management: JIT.java Log message: 2003-07-28 Timothy S. Stack [EMAIL PROTECTED] * kaffe/kaffevm/intrp/stackTrace-impl.h: Add empty EXCEPTIONFRAME()/FIRSTFRAME() macros, these need to be filled in eventually so JVMPI can do backtraces on threads besides the current one. * libraries/clib/management/JIT.c, libraries/javalib/kaffe/management/JIT.java: Remove stale dumpActiveMethods function, it was never implemented anyways. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe kaz
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: kaz 03/07/28 09:16:08 Modified files: . : ChangeLog libraries/javalib: essential.files Log message: 2003-07-28 Ito Kazumitsu [EMAIL PROTECTED] * libraries/javalib/essential.files: Add gnu/java/locale/Calendar*.java ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Other question
Hi Matt, Matt R. Jezorek wrote: Well thank you now it builds great. So I got one other question. How production ready would you say kaffe is. The reason I ask is We are developing a Linux based distro for educational use. We will be including java which is why i am testing kaffe as it is a open project which we love to include instead of Sun's. Most will be used manly as a plugin to the browser and Open Office. So looking to include it in the distro. Let me know if you think its ready for prime-time. Uh, depends on what 'prime-time' means ;) I'm talking with OpenOffice developers about what they need exactly in terms of kaffe features to build OpenOffice. Running OOo's bits written in Java may or may not work, I don't think anyone has tried it yet. Though judging by their import statements, it seems that OOo first needs a good cleanup, since it appears to be using a lot of Sun's internal classes. How much of an impact that has I can't really say. If you want to build OpenOffice using kaffe, join the discussion on the developer mailing list on tools.openoffice.org. There is a mozilla plugin for kaffe, but it hasn't been merged into the main tree due to lack of a developer who can fix it to work with mozilla latest xpcom incarnation. The sources, if you intend to work on it, are here: ftp://ftp.kaffe.org/pub/packages/kaffe-mozilla-oji [1] One of the big prime time issues is that there is no swing. Kaffe works with Sun's swing 1.1.1, but it's a separate download under an awkward license. So you may find yourself with your users wanting to run LimeWire and replacing kaffe with Sun's JDK. To sum it up: if you know what you need, and kaffe fits the need, go for it. It includes some useful bits from 1.4, 1.3 and 1.2 and almost a full implementation of 1.1. But as a full scale replacement for the 1.4 JDK, it's not there yet. As a full scale replacement for JDK 1.2 neither. It should be O.K. for 1.1 applications, if you still run some ;) And it's quite alright for many applications that don't need the more esoteric features of 1.4, like XML processing applications. Of course, if you decide to use kaffe, we'd appreciate your bug reports and patches. You may even get rapid responses to bug reports, like today ;) Writing a java runtime is a huge task, and we can use all the help we can get. Experimental distributors are welcome to join in the fun ;) cheers, dalibor topic [1] Speaking of mozilla: I've heard that Michael Koch is working on a mozila plugin for gcj. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Other question
Hi Matt, Matt R. Jezorek wrote: I will look into a few things and see what I can do. One way I might approach this is install kaffe as default and then put a sun jre package on the update server to let people get it who want it. Let me think about it a bit and see what I can think about and come up with. I might can help here and there :) thanks, I'm looking forward to hear again from you. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hi Tim, Thats cool... As I was thinking about it more, the JanosVM changes are more useful for changes in the jitter than for verifying (Basically, you want to generate code 'optimal' code if the class is loaded, but you don't want to force loading either.) with the exception that loadClass will have a new parameter that allows you to specify to what target state a class should be loaded until. The new method is called loadClassToState, and loadClass simply forwards a call to loadClassToState with the default target state. The reason for this is that, during verification, if I really need to load a class, I don't want to link it (that can cause circular dependency problems when loading on the same thread), I don't understand why this is a problem. Here's why this is a problem during verification. When verify3() is called on a class, the class is CSTATE_PREPARED. Suppose that I am verifying class A and I need to load class B to complete verifying class A. Now, loadClass makes sure a class is processed to CSTATE_LINKED, which is just after verify3() is called. But suppose class B requires class A to be loaded to complete verification. Then loadClass is called, class A is found in memory but it has not yet been processed to CSTATE_LINKED, so the thread tries to verify3() it again. This is legal because it's the same calling thread, so it already has the lock for class A. etc. etc. What I can do instead is to create a new CSTATE_BEING_LINKED or something instead of doing the loadClassToState() method. That probably works...that sound alright? I'm still getting my feet wet in the kaffe core internals, so thanks for helping me out :) Cheers, Rob ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe rob
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: rob 03/07/28 13:12:04 Modified files: libraries/javalib: essential.files Log message: * libraries/javalib/essential.files fixed gnu/java/locale/Calendar_nl.javA to be gnu/java/locale/Calendar_nl.java ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe kaz
In message Re: [kaffe] Kaffe CVS: kaffe kaz on 03/07/29, Ito Kazumitsu [EMAIL PROTECTED] writes: gnu/java/locale/Calendar.java:1: error:Can not found java/util/ListResourceBundle [JLS 7.5.2, 7.6] gnu.java.locale.* are needed at run time but not at compile time. So gnu/java/locale/Calendar*.java can be deleted from essential.files. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] config.frag files for NetBSD
Hi Dalibor, thanks again for the patch. since I'm not sure whether you've got your CVS write access already, I've commited it myself. Would you like to clean up the other platforms as well? AFAIK, freebsd comes with another cross-compilation toolset similar to netbsd's. As you guessed, I have not yet sent PGP'ed identifier to Jim. (I need to clarify several issues whether I can do that with current environment before sending). As far as cleaning up issue is concerned, of course I can do that but I am not so confident this modification works well for all platform. Especially, some platform which has not been maintained by anybody for long time. Is it good to automatically delete all defines not needed for latest configure etc? Or just start from Linux only? Kiyo ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
