Re: PATCH: truncated class handling
Dalibor wrote: On Tuesday 16 April 2002 00:49, Patrick Tullmann wrote: I've attached the ChangeLog entry here. I can check this in, but want to know if I should check it in now, or if we should wait for after the 1.0.7 release. Other feedback or issues are welcomed, too. depends on how experimental it is. On which platforms did you test it? Only one... Linux/x86, debug/jit build of Kaffe. I can pretty easily test several other Kaffe configs. Slightly more of a pain to test on FreeBSD-current/x86. I'll try and get some of those going... In general, it sounds great. I haven't merged the relevant kaffevm changes from JanosVM yet, so I'd say you go first :) :) Thanks. Hmmm... about 50% (by chunk) of the patch applies cleanly to the JanosVM, so it shouldn't be too big a problem, either way. I'm pretty familiar with the JanosVM internals, too. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Success means never having to wear a suit.
PATCH: truncated class handling
I discovered the other day that Kaffe didn't correctly handle truncated class files (it just segfaulted, and threw a null pointer exception). I figured this would be a relatively easy fix (just add some buffer length checks in various places in readClass). It wasn't. The main culprit was kaffeh, which used its own bastarized version of the readClass macros. I bashed on kaffeh until it was able to use the main kaffevm functions for reading classes, and took the opportunity to clean up a bunch of other things in kaffeh (and some in kaffevm). A completely unrelated hack to kaffe/scripts/kaffe.in to automatically figure out a unique name for KAFFE_DEBUG_TEMPFILE is also included. The patch (92k) and a ChangeLog entry are available here: http://www.tullmann.org/pat/kaffe/ I've attached the ChangeLog entry here. I can check this in, but want to know if I should check it in now, or if we should wait for after the 1.0.7 release. Other feedback or issues are welcomed, too. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] The early bird gets the worm, so sleep in. Pat Tullmann [EMAIL PROTECTED]: * kaffe/kaffeh/mem.c, kaffe/kaffeh/Makefile.am, kaffe/kaffeh/java_lang_ClassLoader.h, kaffe/kaffeh/java_lang_Object.h, kaffe/kaffeh/kaffeh-support.h, kaffe/kaffeh/main.c, kaffe/kaffeh/sigs.c, kaffe/kaffeh/support.c, kaffe/kaffevm/Makefile.am, kaffe/kaffevm/baseClasses.c, kaffe/kaffevm/classMethod.c, kaffe/kaffevm/classMethod.h, kaffe/kaffevm/classpath.h, kaffe/kaffevm/code.c, kaffe/kaffevm/code.h, kaffe/kaffevm/constants.c, kaffe/kaffevm/constants.h, kaffe/kaffevm/exception.c, kaffe/kaffevm/file.h, kaffe/kaffevm/lookup.c, kaffe/kaffevm/readClass.c, kaffe/kaffevm/readClass.h, kaffe/kaffevm/support.c, kaffe/kaffevm/utf8const.c: Handle truncated classes in readClass. Also took the opportunity to clean up some really ugly macros, and share more code between kaffevm and kaffeh. Moved the buffer reading macros used by readClass() into inline functions with asserts. Added many 'const' to various 'char *'. Split kaffeh mem-related code into a new file. kaffeh overrides various functions now, but does not override internal header files or macros. Cleaned up the kaffeh java_lang_* headers. Add -Xdebug option to kaffeh, as kaffeh can now use the kaffevm debug.c infrastructure. Moved class-specific constant table parsing macros into classMethod.h (out of constants.h). * kaffe/kaffeh/mem.c, kaffe/kaffevm/utfconst.h: Added as part of above. * kaffe/kaffeh/constants.c, kaffe/kaffeh/constants.h, * kaffe/kaffeh/file.h, kaffe/kaffeh/readClassConfig.h, * kaffe/kaffevm/readClassConfig.h: Removed as part of above. * kaffe/kaffevm/debug.c,kaffe/kaffevm/debug.h: Added READCLASS flag to debug infrastructure. dbgSetMaskStr() now takes a 'const char*'. debug.h is usable in Kaffeh, so many hacks were removed. Made GCC understand that kaffe_dprintf works just like printf, so it can debug the format strings (several debug format strings were fixed because of these valid warnings). * kaffe/kaffevm/findInJar.c, libraries/clib/native/ClassLoader.c Use the new file.h classFile interface, * kaffe/kaffevm/utf8const.h, kaffe/kaffevm/string.c, kaffe/kaffevm/stringSupport.h: To cleanly share the utf8 code between kaffeh and kaffevm, created kaffevm/utf8const.h which contains only the utf8-related functions, types and macros. * test/regression/Makefile.am, test/regression/TruncatedClass.java: Added a new regression test TruncatedClass.java that tests truncated classes. * kaffe/kaffevm/inflate.c, kaffe/kaffevm/jni.c, libraries/clib/native/Runtime.c Minor comment changes and cleanups * kaffe/kaffevm/mem/gc-incremental.c, kaffe/kaffevm/mem/gc-incremental.h, kaffe/kaffevm/mem/gc-mem.c, kaffe/kaffevm/mem/gc-mem.h: Added some asserts to the gc, and some more comments. * kaffe/scripts/kaffe.in: Try to automatically find a unique name for the KAFFE_DEBUG_TEMPFILE.
fix for new rt.jar stuff
Kaffe fails to build for me (and it failed to build in all the nightly
tests last night). It seems that the new rt.jar layout assumed Kaffe
was being built in its source tree.
The attached patch fixes the problem for me, but I so distrust
automake et. al. that I won't claim this is correct, or be the one to
commit this patch without an okay from someone
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
${HOME} is where the .emacs is.
RCS file: /cvs/kaffe/kaffe/libraries/javalib/Makefile.am,v
retrieving revision 1.58
diff -u -b -c -r1.58 Makefile.am
*** Makefile.am 2 Apr 2002 04:52:06 - 1.58
--- Makefile.am 3 Apr 2002 07:20:45 -
***
*** 933,938
rm -f $(srcdir)/$(CLASSFILE)
cp $(LIBDIR)/$(CLASSFILE) $(srcdir)/$(CLASSFILE)
! rt.jar: Klasses.jar
! cp Klasses.jar rt.jar
--- 933,938
rm -f $(srcdir)/$(CLASSFILE)
cp $(LIBDIR)/$(CLASSFILE) $(srcdir)/$(CLASSFILE)
! rt.jar: $(srcdir)/Klasses.jar
! cp $(srcdir)/Klasses.jar rt.jar
Re: Rewriting the GC
Erik wrote: The big problem with walking the stack isn't the Java stack as much as the native stack. You could walk the Java parts precisely, and the native bits conservatively, but I don't know what you'd win anything by doing this. OK, I'm not so familiar with the way Java interacts with native code, but why do we need to walk the native bits at all? Surely C code doesn't need GC? All the native methods in Kaffe, the threading system, the core class loading --- that's all written in C. That code uses the same stack as the Java code. That code uses Java object refereneces left and right, and stores them on the stack. I know the object allocation code in the GC itself relies on the GC scanning the stack to avoid collecting a brand new object (for whom the only reference is on the C stack). If you grep through the core of the VM, it invokes gc_malloc() a LOT. It definitely relies on the GC. Godmar and Tim cleaned things up a lot to avoid creating excessive walkable objects (e.g., many of the structures that hang off a class are explicitly allocated/deallocated) but there are still a significant number of GC objects that are created in C. As I understand GC trade-offs, the big win for precise GC is the ability to update pointers and thus implement a compacting collector. Is there something else you're hoping to get out of precise stack walking? Predictability and speed of GC. You're talking about bogus pointer references in a conservative scan being viewed as pointers, when in fact they're just integers that look like pointers? Most of the literature about that says the overhead is pretty small. I doubt you'd see any performance improvement (I guess things would get worse from having to manage stack maps and the like). As for predictability, I don't see that as a useful goal for Kaffe Remember, Kaffe already gets the benefits of precise GC for most objects. It is just thread stacks and objects for which it has no layout information or specific walk function that cause a conservative scan (and only for those objects). (I wonder what the other conservatively walked objects are, I think there are some still.) Implementating a compacting collector, OTOH, would be really cool. Kaffe could support generational collection (which is what all the real JVMs support AFAIK), and its support for multi-process VMs (the Flux work I do --- KaffeOS and JanosVM) would be much improved. That's just a significant amount of additional work, I believe. You could get an upperbound on the predictability by instrumenting the VM to count the number of references from a conservative scan are the only reference to an object. Many of those will be (I bet) legit references, but a precise stack walk cannot get rid of more than that... Another approach to consider is to implement GC-safe points (e.g., on method calls and backwards branches in Java code). Then you only have to track and update the stack maps at each safe point, There's a lot to be said for this, but since you can allocate unlimited memory in an exception handler, every point that can throw an exception has to be a safe point, which reduces the appeal. Most call points and backwards branches would have to be gc-safe, anyway --- to avoid looong gaps without safe points --- so I don't think exceptions pose any significant problems. While you don't get major wins for the JIT'd code this way (though I think there are some nice ones) a system that supports safe points is (and I'm somewhat guessing here) much easier to write safe native code in --- you don't have to worry about your C code getting interrupted by the GC at arbitrary points, only at safe points you explicitly insert in your code. There are downsides, of course --- like if you forget to put a safe point in somewhere, the GC can be blocked for a long time. -Pat - - --- --- -- -- - - - Pat Tullmann www.tullmann.org Forty-Two. -- Deep Thought
patch for include/Makefile.am
The attached patch causes the Make to abort if kaffeh has a problem. Currently an error return from kaffeh is ignored. (I was getting errors because my Klasses.jar was badly corrupted.) I fixed the problem by including a 'set -e' in the complex shell sequence that invokes kaffeh. -e should cause the shell to bail on an unchecked error. I'm not sure if this is portable, or if there is an alternative automake/autoconf/libtool approved way of getting this behavior. If someone applies this patch, don't forget to regen Makefile.in, too. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] If Gates got a dime each time Windows crashed... Oh, nevermind... Index: Makefile.am === RCS file: /cvs/kaffe/kaffe/include/Makefile.am,v retrieving revision 1.25 diff -u -b -r1.25 Makefile.am --- Makefile.am 19 Aug 2001 20:32:47 - 1.25 +++ Makefile.am 2 Apr 2002 00:38:16 - @@ -126,7 +126,7 @@ stamp-h0all: stamp-kaffeh $(KLASSES_JAR) ## Then, generate each header file, ## but if it does not change, do not touch it - @for f in $(DERIVED_HDRS); do \ + @set -e; for f in $(DERIVED_HDRS); do \ class=`echo $$f | sed -e 's%.*/%%g' -e 's%\.h$$%%' -e 's%_%/%g'`; \ echo $(KAFFEH) -classpath $(KLASSES_JAR) -o $$f $$class; \ $(KAFFEH) -classpath $(KLASSES_JAR) -o stamp-h0$$f $$class; \ @@ -148,7 +148,7 @@ stamp-h1all: stamp-kaffeh $(KLASSES_JAR) ## Then, generate each header file, ## but if it does not change, do not touch it - @for f in $(JNI_DERIVED_HDRS); do \ + @set -e; for f in $(JNI_DERIVED_HDRS); do \ class=`echo $$f | sed -e 's%.*/%%g' -e 's%\.h$$%%' -e 's%_%/%g'`; \ echo $(KAFFEH) -jni -classpath $(KLASSES_JAR) -o $$f $$class; \ $(KAFFEH) -jni -classpath $(KLASSES_JAR) -o stamp-h1$$f $$class; \
Re: GCJ and Kaffe
Jim wrote: I'd also like to see if we plug in and execute pre-compiled objects built with gcj. FYI, Godmar had this somewhat working sometime in late 2000 (maybe?). Getting the Kaffe and GCJ exception mechanisms to play nicely together was, I believe, the last remaining major hurdle. GCJ has probably changed sufficiently to have added some more hurdles. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] All your base are belong to us.
Re: Interesting results...
Just a suggestion: could someone strip wc.java down to a testcase that causes this problem and (assuming its really a compiler problem), name the testcase BrokenCompilerCheck.java or something? Put it early in the test run, too. That will make diagnosing failures much easier in the future. -Pat Works ok with jikes 1.13. With jikes == 1.15 built from their tarball, the file test/regression/wc.java in CVS gives this error in wc.fail java.lang.VerifyError: at pc 5 sp 7 not in range [4, 6] at java.io.PushbackReader.init(PushbackReader.java:32) at java.io.StreamTokenizer.init(StreamTokenizer.java:50) at wc.init(wc.java:72) at wc.main(wc.java:104) wc.class.gz attached, but I'm happy to use 1.13
Re: IA-64 port
John R. Daily wrote: The Mandrake patches work great for the latest CVS version, but don't seem to help for 1.0.6. Are those patches available somewhere? I found a Mandrake(?) webpage listing the ChangeLog for the Kaffe that is distributed with Mandrake(?), but it wasn't obvious if the patch sets were available separately. http://speakeasy.rpmfind.net/linux/RPM/cooker/cooker/i586/Mandrake/RPMS/kaffe-1.0.6-11mdk.i586.html On the other hand, I'm not sure if making them available would get them put into the Kaffe CVS repository. How much has Kaffe changed since 1.0.6? Quite a lot of small changes have gone in (except for the included compiler which has been changed quite a bit, I think). Mostly stability fixes and code clean-ups outside of the compile, if I recall things correctly. Are there plans for a 1.0.7 release? I believe there were some plans several months ago, but I haven't heard anything about those plans since. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: IA-64 port
John R. Daily wrote: I've been working to get kaffe working on Debian/ia64 via libffi, Cool. and I would guess the real problem lies earlier, when memory is being allocated. Probably a good guess. Can anyone suggest mechanisms for tracking down the root cause of this problem? I have essentially zero familiarity with the kaffe code, so I'm flying blind at the moment. You'll want to turn on the debugging code (--enable-debug to configure), then pass '-vmdebug GC_DIAG' to the VM. That will turn on some internal sanity checks in the GC code. There are a bunch of other -vmdebug options '-vmdebug list' (or look in debug.c) for getting a trace of specific parts of the VM. Also, on some platforms the interpreter is a bit more stable than the JIT, you might try that (if the JIT is even enabled, 'kaffe -fullversion' will tell you what you actually built into kaffe.) I don't know who made the existing Alpha support for Kaffe, but it is a bit old, so I wouldn't be surprised if it has rotted a bit. However, I'm pretty sure it worked in the past... Hope this helps, Pat - - --- --- -- -- - - - Pat Tullmann www.tullmann.org This bit of signature was randomly selected. Really.
Re: compiling Kaffe statically?
I am attempting to run Kaffe on a simulator that doesn't support shared libraries. I configured with the --with-staticlib and --with-staticvm options and compiled it. However, when I try to run the VM it is looking for the libnative library. With libtool, libnative.la is just a text file telling the libtool code in Kaffe what to do. So, you need to include those text files in your simulator environment. The text files (should) indicate that the library is statically linked and the libtool code will get on with it. I don't recall if the paths are hardcoded in Kaffe or if its looks through the LD_LIBRARY_PATH for those libraries... The oskit build of Kaffe is fully statically linked, but has to include the .la files in the kernel image. Look at config/i386/oskit/mkimage.sh for hints. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Your research fills a much needed gap.
Re: gdb debugger/kaffe
would like to do symbolic debugging with kaffe using gdb or some other std debugger. Look at FAQ/FAQ.xdebugging, I think that's exactly what you want. (You should get the CVS version of Kaffe if you haven't already.) Also, use the --enable-debug configure option. That enables -vmdebug and turns on C-level debugging (if C-level symbols aren't normally included, I don't remember). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Ignorance more frequently begets confidence than does knowledge.
Re: gdb debugger/kaffe
I saw that FAQ but it sounded a little obscure.. cross language debugging support.. not sure what it meant. it sounded like cross compilers. It means Java + C debugging at the same time. Most debugging support in Kaffe can best be described as a hack (or a bunch of hacks), and most of it is targetted at VM developers not Java developers. The Kaffe VM doesn't support the JVMDI interface. the FAQ says it handles source files/line numbers but does not support symbol tables. Where? It doesn't use the debugging info included in the .class file, but instead is built from the information the VM maintains about each class/method. However, variable locations and type disassembly information isn't generated in a way that GDB can parse it. (Look at the pobject macro in developers/gdbinit to accomplish that.) so I am starting to wonder if kaffe just isnt debugger friendly. does anyone use a debugger w/kaffe? I turned up a big gdb script on the net somewhere. Look at developers/gdbinit. There are a bunch of GDB macros for inspecting various java-level constructs from GDB. This is probably not what you want either. I also cant figure out why it comes with jdb apparently exactly the same as the sun version. (the man pages are the same). running jdb that comes with kaffe (redhat 7.1), I get this error msg java.lang.ClassNotFoundException: sun/tools/ttydebug/TTY at java.lang.Class.forName(Class.java:native) at java.lang.Class.forName(Class.java:52) You might try it with Sun's class files? I have no idea if that would work with Kaffe. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This signature witticism intentionally left blank.
Re: UTF8 Error
Partha wrote: Kaffe aborted with the following error Kaffe:utf8const.c:204:utf8Const, Release:Assertion 'utf8 - nrefs = 1' failed What is the reason for this error? It means the VM is freeing an internally-reference-counted UTF8 string constant twice. How to fix it? Several bugs that exhibit this behavior have been fixed in the CVS repository. I assume you're using the stable 1.0.5 or 1.0.6 release? (Try 'kaffe -version' or 'kaffe -fullversion') I do not believe there are any workarounds. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: arm cross-compile problem
Mark Horton wrote: The only thing printed out during configure that seems unusual is the folowing line: configure: warning: when cross compiling, you may want to set ac_cv_c_char_unsigned to yes or no Probably not a big deal. I have not been able to figure out how to set ac_cv_c_char_unsigned. I've tried various things but none have made a difference. I continue succesfully with make and make install. I then tar up /mnt/big/java/kaffe-1.0.6 and scp it over to the ipaq. When I untar it and try to run anything it seg faults. Did you install it in /mnt/big/java/kaffe-1.0.6/ directory on the ipaq? (I can't remember if this is required or not, though). Can you run it under a debugger and get a back trace of where the fault is? Alternatively, try configuring --enable-debug, and run with '-vmdebug ALL'. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This signature witticism intentionally left blank.
Re: Can/How I disable threading?
The GC runs in a separate thread. I'm pretty sure there is no easy to way to disable threading in Kaffe and still get a usable system. If you disable GC and finalization, you might be able to get away with one thread. Actually, if you make the initial heap large enough, the GC just won't run for most small programs, and the thread-switch code won't get invoked. You might try patching the jthread code to save/restore the relevant simulator state. That's all that setjmp/longjmp do, but they do it for the underlying host OS machine. If you include your simulator's stack/eip/etc you might be able to support threading Maybe. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] All your base are belong to us.
Re: Can/How I disable threading?
Min Xu wrote: This one seems promising! So where can I find the code to separate the JVM from the thread? E.g. Bypassing the thread creation in the JVM init; avoid invoke GC finalization, etc. If I understand correctly, the problem is when the JVM performs a thread switch, right? All I'm suggesting is that you avoid giving the the JVM a reason to perform a thread switch. All the code and call points are still there, you just hope the thread switch won't be called. :) If you want to hack the C code to actually prevent this, I think the place to look is in baseClasses.c::initialiseKaffe(). Or you could emasculate jthread.c:jthread_create(). The simulator doesn't have any functions to support interupt during the simulation, as far as I know. The basic signal handling is not supported in the simulator, which means, the simulator can not stop the current simulation and jump into the simulatee's signal handling code simulate that code and resume the main program simulation after that. I think this just means you can't have preemptive threads, which are not required by the Java model, even. I know Kaffe didn't support preemption for a while. You can still support context switches during at defined points (i.e., when invoking most jthread* functions). System.c:384: java_lang_System_initProperties: Assertion `r = 0' That's the uname() system call returning an error. You can probably fixup the System.c code to gracefully handle the error (e.g., by setting the os.* properties to unknown). This is an arraycopy() error during the loading of the basic resources. I know this problem has come up for others in the past, but I do not remember what the actual problem was. Something about the default resource objects (usually character maps) not being visible/available. Internal error: caught an unexpected exception. Please check your CLASSPATH and your installation. java/lang/ArrayStoreException at java.lang.System.arraycopy(System.java:native) at java.lang.String.getChars(String.java:293) at java.lang.String.toCharArray(String.java:504) at java.util.StringTokenizer.init(StringTokenizer.java:35) at java.util.StringTokenizer.init(StringTokenizer.java:30) at kaffe.lang.SystemClassLoader.findResources(SystemClassLoader.java:49) at java.lang.ClassLoader.getResources(ClassLoader.java:188) at java.lang.ClassLoader.getResource(ClassLoader.java:165) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:215) at java.lang.ClassLoader.getSystemResourceAsStream(ClassLoader.java:227) at java.lang.System.clinit(System.java:49) at java.lang.ThreadGroup.add(ThreadGroup.java:86) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: What's the thread model on Linux?
But what I found is that kaffe cannot even support 200 users. Interesting! Only the unix-jthreads code gets tested and used a lot, so I wouldn't be too surprised that unix-pthreads can't keep up with unix-jthreads. In any event, the unix-pthreads code should be able to support more than 200 threads. It could very well be a simple problem in the unix-pthread code. Shouldn't kernel thread offer better performance? Only on an SMP machine. Kaffe's jthread implementation is very good about switching internal threads when blocking I/O operations are performed. That is traditionally a bottleneck for user-mode threading implementations. User-mode threads are much lighter-weight than kernel threads (no need to enter the kernel for a thread switch, and no need to use kernel support for critical sections). However, on an SMP machine, no user-mode thread package can take advantage of the multiple CPUs. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Success means never having to wear a suit.
Re: What's the thread model on Linux?
Does Kaffe use jthread or native thread when compiled on Linux (kernel 2.2.16)? By default, Kaffe always uses the jthread threading package (look for 'with_threads' in configure.in and config/*/*/config.frag). It can be compiled to use kernel threads on Linux (--with-threads=unix-pthreads). To see what version was compiled in to a particular executable, use the -fullversion argument to kaffe. (Hmm, config/i386/linux/config.frag references 'linux-threads' when it should reference 'unix-pthreads' I think.) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] He who dies with the most toys is still dead.
Re: Another problem with latest CVS version
java GCTest sometimes it succeeded, but sometimes I got the following error: java.lang.IllegalMonitorStateException This looks like it might be a locking problem. Since you're not on an x86, I'm not too surprised. You might look around in your platform's md.h, and kaffe/kaffevm/ksem.h to see if anything is amiss. Sorry I can't give any better hints on debugging this. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Don't hate yourself in the morning -- sleep until noon!
Re: cvs Klasses.jar not up to date
It seems that the javac wrongly parsed source files (such as HelloWorldApp.java). Below is the output of gmake check, (only first 12 files' output shown) Do you know what 'javac' you're running? The regression test suite will use jikes, I belive, if it can find it. The best way to figure this out is to pass 'VERBOSE=1' on the make check command line. Try this (cd into test/regression first, its easier): make check VERBOSE=1 This will print the command its using to compile the .java files (the line after JAVA_SRCS=...). Also, is jikes or any other java compiler installed and visible in your path? (Running 'which javac' and 'which jikes' should find them if they are.) PASS: HelloWorldApp.class.save This means the Kaffe you compiled can at least run the pre-compiled HelloWorld. A good sign. ./TestIntLong.java:7: error:Syntax error: unexpected token: End of file FAIL: TestIntLong.java This is very odd, as line 7 isn't anywhere near the end of the file. You might look at your TestIntLong.java and make sure it looks okay. The only thing I can think of would be sort of dos/unix end-of-line mixup. I have no idea how that might happen, though. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: [PATCH] Deflater.java (for Ant)
I have been trying that Jakarta Ant work with Kaffe. Then, I found a problem at java/util/zip/Deflater.java. Exception is thrown when setLevel() is called with default compress level (Deflater.DEFAULT_COMPRESSION = -1), but SUN's Deflater.java works fine then. Thanks for tracking down the problem and fixing it! I've committed your patch and rebuilt Klasses.jar. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This bit of signature was randomly selected. Really.
Re: a problem when running java program on kaffe
Yong Chen wrote: ChangeLog head: Mon Jul 24 14:00:00 PDT 2000 Tim Wilkinso That's the official 1.0.6 release. The latest CVS snapshot will probably fix your problem, then. See http://www.kaffe.org/ for details on fetching the latest version. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This space unintentionally left blank.
Re: Error compiling java.lang.Float
Edouard recently checked in a patch to java.lang.Float with this message: revision 1.16 date: 2001/05/07 10:04:19; author: egp; state: Exp; lines: +13 -6 Made POSITIVE_INFINITY, NEGATIVE_INFINITY, NaN, MIN_VALUE and MAX_VALUE compile time constants. This is required by many Jacks test (105 new tests succes with this patch). I'm not sure if the Jikes is wrong or if the constant is really too small. Hope this helps, Pat Carlos Valiente wrote: Trying to rebuild Klasses.jar with jikes 1.1.3 I get the following error: !-- - SNIP --- --! carlos@alfalfa:~/src/java/kaffe-cvs/build/libraries/javalib$ make Klasses /bin/sh ./rebuildLib Compiling classes ... Found 1 semantic error compiling java/lang/Float.java: 30. public static final float MIN_VALUE = 1.4012984643248170709e-45f; *** Error: Invalid floating-point constant. make: *** [lib/stamp] Error 1 !-- - /SNIP --- --! Any ideas? Carlos Valiente [EMAIL PROTECTED]
Re: kaffe native interface
Nic Ferrier wrote: Is native more efficient? Yep. You can access the java objects more directly. The 'kaffeh' tool generates a .h file that maps a java type to a C typedef, so you can access fields simply and directly. Or is it simply that jni was firmed up long after most of kaffe was written and native is the historic native interface for Kaffe? This is also true. Definitely the JNI support was added well after native code support was finished. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: How to modify the makefile of kaffe
Fang Wei Jian wrote: I guess that it will be more easier to modify Makefile.am, then run automake, and then run configure. I tried this, but the resulted Makefile doesn't work. You need the correct suite of tools. The script developers/autogen.sh will run them in the correct order. You need to get a CVS snapshot of automake. You need to *not* use a CVS snapshot of autoconf. I have a web page about the tool chain to use: http://www.cs.utah.edu/~tullmann/kaffetools.html I seem to be using a "1.4a-dep-2313" snapshot of automake, which you can download from the above page. I use autoconf-2.13 (which is the last stable release of autoconf). The latest CVS autoconf will *not* work with Kaffe's Makefile.am Hope this helps, Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Mean people suck.
Re: java_lang_Object twice defined
[EMAIL PROTECTED] wrote: Hi, When I cross-compile the kaffe, I met this error. Does someone know this? That's very odd. There shouldn't be a definition of Hjava_lang_Object in java_lang_Object.h. (Yes, that is a bit odd, but its true.) Look at kaffe/kaffeh/support.c:startInclude(). It specifically skips java_lang_Object and java_lang_Class because those have magical definitions provided explicitly by hand, and do not have java fields. You might nuke include/java_lang_Object.h and try re-running make on it in that directory to see what the arguments to kaffeh are. Then you'll have to debug kaffeh for that test case (should be pretty straightforward). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] That which does not kill you just didn't try hard enough.
Re: mips problems
[EMAIL PROTECTED] wrote:
assertion "fidx nrTypes size != 0" failed: file
"mem/gc-incremental.c", line 859
You might split that assert into two separate ones, so that its
clearer which one is blowing up. I wouldn't be surprised if size was
zero because of some other failure in the system. Send me a backtrace
and I can give you some more hints...
- are there other parts of kaffe i can test to see that at least something
is working right?
Does 'kaffe -fullversion' work? That's really basic... :)
Beyond that, the pre-compiled HelloWorld is pretty hard to beat. I
guess you could remove the println(), that would avoid some stuff, but
still the bootstrap will pull in lots of Java code (lots of static
initializers get run before main).
- any suggestions on how to start debugging this?
Configure with --enable-debug, and use the '-vmdebug' command line
option ('-vmdebug list' for help). There are also a bunch of gdb
macros in developers/gdbinit. (Though some are quite stale, and others
are x86-specific).
Thanks in advance for any suggestions.
Hope this helps,
Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
He who dies with the most toys is still dead.
Re: kaffe porting
1) If data type sizes in the compiler do not have enough precision as expected by the java(for example long is 64 bits in java and there is no equivalent data type in the c compiler) then how to implement this extra precision. This would be tough, as the 64-bit integer 'jlong' is used quite a bit in the VM. Look at kaffe/include/jtypes.h to see what has worked on other platforms. You could grep through the sources to see if fixing up operations on jlong can be changed manually (I would guess its a big job, though.) Does the iPaq toolchain support 64-bit integers? 2) If there is no malloc() support from the compiler/OS can we follow some strategy to manipulte the statically allocated memory? The kaffe run-time is pretty clean about doing all of its allocations through the GC. You could probably get the GC to use statically allocated memory (instead of sbrk'd memory) pretty easily. I belive others have done this (or something similar). 3) If the file system support is not there providing some hooks in the memory (with the help of simulator) can kaffe be used to load ROM loaded class files. This shouldn't be too hard. All the file system accesses are indirected through the jthread layer. 4) Can we provide some alternative if posix compliant signals and non-blocking i/o are not present with the toolset. Look at FAQ/FAQ.jsignal for details on signal usage in Kaffe (specifically with the jthread threading layer in Kaffe). 5) If the DLL facility is not provided can we follow some strategy to statically link native methods? If so, will there be any security issues? Creating a statically linked VM is a configure time option (--enable-static and --with-staticvm). Its not that easy, as libtool requires being able to read its .la files for the statically linked libraries in any case. If anybody has some directive links for some/all the questions please do help me. has anybody already ported kaffe to one such environment? I belive Kaffe has been ported to a couple of small environemnts. www.pocketlinux.org is probably the one receiving the most attention. (Perhaps the pocketlinux version of Kaffe would make a better starting point?) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Not many people realize just how well known I am -- Anonymous
Re: Kaffe on embedded MIPS board
kjlin wrote: Is it the problem of the kaffe i made or just the tested java code ?? Any suggestion will be appreciated!! You might try '-vmdebug EXCEPTION' to see some more information about the exception that was generated. Also, since the problem happens during initialization, '-vmdebug INIT' might give you a clue as to where the problem is occuring. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Research is not just an adventure, its a job.
Re: Ahead Of Time compilation with Kaffe
Philippe Laporte wrote: If you mean simply to compile the classes before running them, this is done with gcj in the pocketlinux version Whoa! Really? I know `vanilla' Kaffe has some rudimentary support for GCJ; is that what the pocketlinux version uses? Has it been improved from what is in Kaffe? Are there any plans to merge the stock Kaffe tree and the pocketlinux Kaffe tree? Or are you guys forking your own open source project?? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] A closed mouth gathers no foot.
Re: Re[2]: slowLockMutex / putHeavyLock
Maxim Kizub wrote: GB Which COMPARE_AND_EXCHANGE macro does it use? This is still an important question. There is a completely bogus definition of COMPARE_AND_EXCHANGE() for architectures on which we do not have an atomic compare and swap operation. In locks.c, change the second definition of COMPARE_AND_SWAP() to a #error directive and recompile. (We should probably do this, or perhaps protect it with jmutexes?) Let me try. But note - sometimes I had asserts related to synchronization, and they were "false". I mean, I have a dual processor machine, and, for example, and asseret assert(xxx==0 yyy==0) was caught, but debugger shows, that both xxx and yyy are nulls. Probably, that's because of my dual-processor computer... That seems pretty unlikely to me... [... backtraces ...] Ok, I hope this will help. BTW, I see now that this is a secondary error, because one of threads tryes to throw an error "IllegalMonitorState", but anyway - 1. why program has caused it? I belive the synchronization primitives are fubar on your system. It could be the jmutex implementation, or (my guess) the COMPARE_AND_EXCHANGE macro. 3. Take, for example, this code: [ _lockMutex() ] as you see - lkp is not protected at all. The COMPARE_AND_EXCHANGE is supposed to provide all the protection. Have you looked at FAQ/FAQ.locks? It tries to describe the locking algorithm (thought I think its wrong wrt to the exact relationship between threads and ksems.) If val != 0, this doesn't mean that in next statement it's != 0, i.e. in this time another thread may execute some code to change lkp. I'm not sure about this... Mostly because the scenario you describe could happen on a uniprocessor (by switching threads right after the val == 0 check)... Still, I can't convince myself that you're wrong by looking at the code. However, instead of using spinon/spinoff, I think the (val == 0) check could just be replaced with an immediate call to COMPARE_AND_EXCHANGE (which should be atomic wrt the COMPARE_AND_EXCHANGE in _unlockMutex() that sets *lkp to NULL). Anyone else want to chime in with a clue on this stuff? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: Add javax.* packages
My approach so far has been: I have a new package I wish to create, say called javax.new So I created a new folder in the libraries/extensions folder, and then copied the directory structure and makefile.am format from the servlet package that is located here (obviously changing "servlet" to "new" wherever this is appropriate). You've got the right approach. I've got a similar library installed, and it works. (Though I performed all the black magic several months ago and, of course, have forgotten the most critical bits.) However, when attempting to use these makefiles an error is thrown as it doesn't know how to build the new.jar archive. Any ideas? Could you send me/us the actual error message? You updated the libraries/extensions/Makefile.am to include your new directory, right? Does the 'build-classes' target work if you invoke that directly? (Just cd into your object tree libraries/extensions/new/ and run 'make build-classes'.) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] It said "Windows 95 or better" so FreeBSD should run it.
jar tool bug
The jar tool blows up if a zero-byte manifest file is provided. Sun's jar tool does not blow up. Here's how to reproduce it: $ touch manifest $ jar -cfm asdf.jar manifest manifest You'll get something like this: java.io.IOException: premature EOF, line 1 at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:38) at java.lang.Exception.init(Exception.java:24) at java.io.IOException.init(IOException.java:25) at java.util.jar.Manifest.read(Manifest.java:247) at java.util.jar.Manifest.init(Manifest.java:36) at kaffe.tools.jar.Jar.createJar(Jar.java:886) at kaffe.tools.jar.Jar.processJar(Jar.java:399) at kaffe.tools.jar.Jar.start(Jar.java:60) at kaffe.tools.jar.Jar.main(Jar.java:39) Sun's tool creates a valid jar file. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "I'd kill for a Nobel Peace Prize." -- S. Wright
Re: jar tool bug
Archie Cobbs wrote: Sun is wrong :-) A valid manifest file always starts with Manifest-Version: 1.0 But we should probably be compatible I guess. Ah. Perhaps a better option than being bug-compatible is to throw an JarException with a better message than "premature EOF, line 1"? I checked jdk 1.1.7 and 1.2 (don't have a 1.3 around). Both accept empty manifest files. Also, 1.2 at least throws an error for garbage-laden manifest files (1.1.7 silently accepts them...). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "I'd kill for a Nobel Peace Prize." -- S. Wright
Re: [Q] Assertion failure on Linux/Alpha
[EMAIL PROTECTED] wrote:
The KREALLOC at line 1876 in classMethod.c is trying to reallocate
iface-implementors array of shorts to a size of 20. Down in gcRealloc(),
gcRealloc() is called (line 1025) and the original memory pointed to
by mem (which is iface-implementors of the clazz in
computeInterfaceImplementationIndex) is copied to newmem.
I think what is happening is that a block on the freelist is being
allocated and not removed from the freelist.
Kaffe's GC uses the data portion of a gc_unit to store the "next"
pointer in a free block. Thus, if the block isn't really free, the
"next" pointer will overlap with the first word of data in the data
block. Or, in your case, I'm guessing that the realloc copies the
data from the old block into the new block, which is still on the
freelist. The data just happens to be all zeros, so it sets
next to NULL.
What baffles me is the reason for this memcpy setting
freelist[3]-list-free-next to NULL. Is this what it should do?
If so I suspect some other book-keeping stuff in freelist[3] is not
correctly updated. freelist[3]-list right after memcpy is as
follows:
The freelist is just a list of gc_blocks. (A gc_block is a 8K chunk of
identically sized allocation units. See kaffevm/mem/gc-mem.h for
useful comments on the data structure.) Since a gc_block may have
some allocation units allocated and some free, each gc_block has a
linked list of free units.
(gdb) p *freelist[3]-list
$25 = {
magic = 0,
free = 0x120205e20,
next = 0x0,
nfree = 0x0,
inuse = 1,
size = 40,
nr = 194,
avail = 11,
funcs = 0x120204000 blah
state = 0x1202040c2 blah
data = 0x120204188 blah
}
From the this you can see the gc_block in question contains 40-byte
allocation units, there are 194 in the gc_block (194 \* 40 = 7760),
there are 11 available blocks, so the chain from the 'free' pointer in
the gc_block should point to a chain of 11 free objects. ('nfree'
points to the next gc_block with 40-byte allocation units that has
a non-zero avail. In this case, there are no more 40-byte blocks)
One odd thing is that the "magic" word at the header of the block is
not the magic value "0xdodecade". Though the rest of the block is
well-formed...
If you run Kaffe with '-vmdebug GCDIAG' it will turn on a bunch of
sanity checks in the GC system. That might trigger a problem earlier
in the GC. My guess is that there is either some sort of buffer
overrun that is corrupting the gc data, or some 64-bit pointer-related
goof (or both).
If GCDIAG doesn't turn up anything useful, you'll need to figure out
why gcRealloc is using an object that the gc_block thinks is free.
You might put some code in the gc_heap_malloc() and gc_heap_free() to
walk the freelists of this particular block and check that the
freelist has 'avail' elements in it.
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
A closed mouth gathers no foot.
no java.util.zip.ZipFile.size()
The size() method on java.util.zip.ZipFile seems to be missing. (It
is documented to return the number of entries in a ZipFile.)
The attached patch should add it. (I added a new native method on
ZipFile.java, getZipFileSize0). The size was stored in the jarFile
struct's 'count' field.
Let me know if this passes whatever standards we have, and I'll check
it in. :)
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
This signature witticism intentionally left blank.
Index: libraries/javalib/java/util/zip/ZipFile.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/util/zip/ZipFile.java,v
retrieving revision 1.3
diff -u -r1.3 ZipFile.java
--- libraries/javalib/java/util/zip/ZipFile.java1999/04/25 13:42:28 1.3
+++ libraries/javalib/java/util/zip/ZipFile.java2000/09/26 23:18:01
@@ -71,6 +71,11 @@
return (name);
}
+public int size()
+{
+ return getZipFileSize0(zip);
+}
+
protected void finalize()
{
try {
@@ -85,5 +90,6 @@
private static native ZipEntry getZipEntry0(Ptr zip, String zname);
private static native Vector getZipEntries0(Ptr zip);
private static native byte[] getZipData0(Ptr zip, ZipEntry ze);
+private static native int getZipFileSize0(Ptr zip);
}
Index: libraries/clib/native/ZipFile.c
===
RCS file: /cvs/kaffe/kaffe/libraries/clib/native/ZipFile.c,v
retrieving revision 1.12
diff -u -r1.12 ZipFile.c
--- libraries/clib/native/ZipFile.c 2000/08/26 22:21:57 1.12
+++ libraries/clib/native/ZipFile.c 2000/09/26 23:18:01
@@ -39,6 +39,12 @@
closeJarFile((jarFile*)zip);
}
+int
+java_util_zip_ZipFile_getZipFileSize0(struct Hkaffe_util_Ptr* zip)
+{
+ return ((jarFile*)zip)-count;
+}
+
struct Hjava_util_zip_ZipEntry*
java_util_zip_ZipFile_getZipEntry0(struct Hkaffe_util_Ptr* zip, Hjava_lang_String*
zname)
{
Re: how to setup dev env with kaffe?
I was playing a little with kaffe as a replacement for JVM from Sun's jdk, but I ran into trouble. What sort of trouble? (The swing stuff is answered below.) Could someone let me know how to setup a working development environment that would have the same capabilities as Sun's jdk, but using kaffe and some other compilers instead? Kaffe comes with its own compiler (kjc), which has some known problems, but is sufficient for most things. If you're going to do a lot of compiling, I suggest getting 'jikes', though. (I would like to run Swing, for example - what modules do I have to get from Sun as an addition to Kaffe JVM so I could run Swing apps ?). You need to get the Swing.jar to run Swing apps on Kaffe. I think you can get that from here: http://java.sun.com/products/jfc/download.html You'll have to add the Swing.jar to your classpath or put it in Kaffe's lib/share/kaffe/ directory. If someone wants to double check this info and update the FAQ.awt (or create a FAQ.swing), I'd check it in. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "I'd kill for a Nobel Peace Prize." -- S. Wright
Re: some regression test of kaffe 1.0.6 failed on linux
Fang Wei Jian wrote: I re-did the regression test. The system was not busy, cpu idle time is 86.7% and 97.1%. Do you have two CPUs or did you make two runs of the test? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] If Gates got a dime each time Windows crashed... Oh, nevermind...
Re: JNI Problem
I wrote:
Prashant wrote:
According to my knowledge about linux, whenever JVM call
"System.loadLibray("Hello")" function, it will search for the library (which
we created "libHello.so") in the "/usr/lib" or "/lib" directory.
You can usually set LD_LIBRARY_PATH to a directory to search there,
too.
One more suggestion.
If you add a library to /lib or /usr/lib (or anywhere else in the
standard library directories), I believe you have to re-run 'ldconfig'
to get it to update its cache of libraries. Run 'ldconfig -v' to see
if that, at least, finds your libHello.so.
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
Your research fills a much needed gap.
Re: Problems with kaffe-1.0.6 on alpha
Simon Greaves wrote: I extracted a fresh copy of the source tree and ran 'configure --enable-debug' which seems ok. Then I ran 'make' which fails whilst compiling kaffe/kaffevm/debug.c: Oops. I'll fix that one. (We should be using 'jlong' everywhere... though that causes some problems elsewhere...). Your fix should be good enough for the Alpha version. Trying the suggestion above with my simple 'HelloWorld' class: % /usr/local/bin/kaffe -vmdebug GCDIAG Samp mem/gc-mem.c:315: failed assertion `blk-free != 0' Abort (core dumped) Could you get another GDB backtrace from the core file with the -vmdebug GCDIAG argument? Perhaps it blew up earlier with the GC "diagnostics" turned on. % /usr/local/bin/kaffe -fullversion Nothing odd reported here. Good. Ah. I had rather blithely assumed Alpha's were supported... Can anyone clarify this? If it's a portability issue, I'd be prepared to put some effort into getting it working, though time (and ability :-) may be a limiting factor. Well, if you want to try tracking this down further, you might avoid the JIT entirely. Re-configure with '--with-engine=intrp'. See if that builds and passes the checks. Hopefully someone can chime in with actual experience with Kaffe on an Alpha... Also, if you're interested in working on this, you should probably get the most recent CVS snapshot (see http://www.kaffe.org/CVS.html). You can check where the classes are actually being loaded from by running a debugging build of Kaffe like: 'kaffe -vmdebug INITCLASSPATH asdf' That'll print full paths to various .jar files Kaffe is using. Looks ok to me.. Yep, looks good to me too. As long as there isn't anything funny in ".". Hmm... looking through the logs in config/alpha I messages like: Follow ``Calling Standard for Alpha Systems'' and add exceptions handling for Dec OSF/1 with libexc. @@@ Be careful, it's not yet working. @@@ Hopefully, "working" isn't too far off. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Does the name `Pavlov' ring a bell?
Re: compile error of javac
Okehee Goh wrote: Is there anyone who has an idea about how to fix it? Make sure your CLASSPATH doesn't have any of Sun's stuff in it. (Best to just leave it completely undefined, Kaffe will figure out where its libraries are.) Make sure 'kaffe -version' works. Best to use a fully qualified path to the installed Kaffe executable. Then try a simple bit of Java code: 'kaffe at.dms.kjc.Main -h'. (That should print out kjc's help information.) If that works, then it can execute at least some Java code. If not, please run Kaffe under GDB and get a backtrace: 'env KAFFE_DEBUG=gdb kaffe at.dms.kjc.Main -h' -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Your research fills a much needed gap.
Re: Problems with kaffe-1.0.6 on alpha
I've just compiled kaffe-1.0.6 with gcc-2.95.2 on an AlphaServer running Digital UNIX 4.0D. Configure, 'make' and 'make install' all seemed to go ok (well except gcc complained about some 'va' stuff being redefined) but 'make check' fails miserably, dumping core, eg: If you re-configure with "--enable-debug", and then run with '-vmdebug GCDIAG', Kaffe will run a lot of sanity checks on the heap for each allocation. Also, 'kaffe -fullversion' will tell us which threading system and which jit/intrp engine is being used. From the GDB backtrace, its loading 'java.lang.Short' which is the 11th basic class to be loaded... perhaps there's something going funny in the JIT? I've no idea what the status of Kaffe on Alpha is (frankly, I'm surprised it got as far as it did :)... % /usr/local/bin/java Samp mem/gc-mem.c:315: failed assertion `blk-free != 0' Abort (core dumped) (Hmmm.. memory, garbage collecting...) The specific error you're seeing is that the GC system finds a page of objects on its free list, but when it looks, the page claims to have no actual free objects. This is an internal consistency check, and usually indicates that something is trashing the gc block header (with a zero in the right spot). So, have I stuffed up here or is there a problem? BTW CLASSPATH is not defined. Good. You don't have a stale installation of Kaffe lying around that might be getting in the way? You can check where the classes are actually being loaded from by running a debugging build of Kaffe like: 'kaffe -vmdebug INITCLASSPATH asdf' That'll print full paths to various .jar files Kaffe is using. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Mean people suck.
Re: TestNative.c
Anyway, I get the SIGSEGV and the last step I can trace it to is callMethodV (coming from Kaffe_callStaticVoidMethodV(...). I don't think you're actually getting a fault in TestNative. Its just that TraceNative.something happens to be the last symbol in Kaffe's text segment on Linux, and your backtrace in gdb is showing *jit* code map to TestNative. You might try using the gdb macro 'findnativemethod' defined in developers/gdbinit to find the actual native method that is causing problems. Or, compile kaffe with cross-language debugging support and use GDB (at least to get the method names). Look at FAQ/FAQ.xdebugging. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This signature witticism intentionally left blank.
Re: Re: Blocked Threads with JNI loop
I tried it with the Call to Thread.sleep(). Blocking ends! Glad that fixed it. But there is a Call to a select() statement which is blocking for 1 second. In this time the other threads are blocked again. Is the select doing anything more than a timeout? If there are any valid file descriptors in the select(), then the you really need to re-write the code to use the VM's file interfaces. JNI might provide such an interface. The KaffeVM (and, I would guess, all other VMs) assumes it has complete control over the threading (locking, blocking, switching). It also assumes that it controls memory allocations, file accesses, network access, etc. Anytime you do non-trivial operations in your C code attached to a JVM you will probably step on the JVM's toes. Sometimes this may not matter (e.g., you just block the whole VM while you do a blocking read on a file descriptor), but you can mess things up (malloc and threading especially). But where is the difference to the sun jvm, is it the threading system? Or the JNI Implementation? I don't know enough about JNI to say, but I belive Kaffe's JNI implementation is up to speed. Note that select() and sleep() are not part of JNI. (Right?) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere
Re: Priority inherentance protocol in Kaffe ?
I would like to implement the 'priority inherientance' protocol into Kaffe on Linux platform. But, as I know, there is no 'pthread_mutexattr_setprotocol' function in Linux. You might have better luck adding priority inheritance to the unix-jthread threading system, as the locking, unlocking, and scheduling are all under Kaffe's control. Does any one know how Kaffe carry out 'priority inherientance' in unix-pthreads for Linux jit3 engine? If you really want to use pthreads, you could try cheating (for example, manually tweaking a thread's priority when it takes/releases a lock). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Indifference may cause the downfall of mankind, but who really cares?
Re: allocating objects
Johan Andersson wrote: In object.c, the function newObject(...) allocates the object. But I can't find out who is calling newObject(...) or when. There is a 'new' instruction which gets compiled to an invocation of newObject(). Look at kaffe/kaffevm/jit3/kaffe-jit.def. Look for 'NEW'. Via many macros, 'soft_new' is eventually called, which processes and loads the .class file, and calls newObject(). When is the constructor called? The bytecode contains an explicit call to a new object's constructor. Can anyone help me out? You should look into disassemblers for .class files. 'javap' which ships with kaffe doesn't have support for disassembly... though it would be a very educational project to add such support! Its a pure-Java application, in kaffe/libraries/extensions/tools/javalib/kaffe/tools/javap/. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Mean people suck.
Re: Rebuilding error with unix-pthread
Erik Hu wrote: I am new to Kaffe and I would like to rebuild with unix-ptherad + interpreter. I have some problems. Does any one know how I can rebuild the Kaffe with unix-pthread ? What OS are you trying this on? Despite the name, it really only "works" on Linux. There are some known issues, but it should compile. Did you re-configure in a "dirty" directory? If so, try configuring in a clean directory (create ../foo; cd ../foo; ../kaffe/configure options;). If that fixes it, there's probably a bug in the configure goo. ../kaffevm/.libs/libkaffevm.so: undefined reference to 'virtualMachine' ../kaffevm/.libs/libkaffevm.so: undefined reference to 'soft_fixup_trampoline' Do you know which engine it was trying to use (intrp, jit or jit3)? There should be an indication in the configure output. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Your research fills a much needed gap.
Re: How can I get debug messages?
How can I use DBG macros in the C codes (.../clib/awt/X/*.c) ? I compiled Kaffe with --enable-debug. What else I have to do ? If you want to see the result of the macros, you need to run Kaffe with the '-vmdebug' option. Try 'kaffe -vmdebug list' to get a list of debug options. Then, pass a comma-separated list of options via -vmdebug. For example: 'kaffe -vmdebug JTHREAD,JARFILES'. This will show all the DBG_JTHREAD and DBG_JARFILES macros. For the AWT stuff, you should use 'AWT'. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Does the name `Pavlov' ring a bell?
Re: where to get kaffe snapshot
Nic Ferrier wrote: The CVS is the always the most up to date release of Kaffe (it is what the developers use to work on the code) but it is not gauranteed 100% to work since a fix in one area might break another. Yep. Regression tests (AFAIK) are not undertaken except when a release is performed. Well, there is a regression test suite (with 102 tests in it now) that's pretty easy to run via `make check`. It seems most of the developers do, even. The problem is, of course, that Kaffe supports N platforms, M thread systems, and Q configurations, so its not really usually an exhaustive check (most developers have 1 platform and 0 time). Kaffe also has a nightly tester that checks-out, compiles, and runs the basic tests under 5 different configurations (on FreeBSD). For details check out http://www.cs.utah.edu/flux/janos/kaffe.html. So, I would say that on FreeBSD (and therefore probably Linux), the CVS snapshot is generally pretty reliable. Of course, its not guaranteed to be. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This bit of signature was randomly selected. Really.
Re: exception.c:250: dispatchException: Assertion...
Kaffe: jthread.c:1633: handleIO: Assertion `(__extension__ ({register
char __result; __asm__ __volatile__ ("btl %1,%2 ; setcb %b0" : "=q"
(__result) : "r" (((int) ((i))) % (8 * sizeof (__fd_mask))), "m" ((( (
readsPending))-__fds_bits)[(((i)) / (8 * sizeof (__fd_mask)))]) :
"cc"); __result; }))' failed.
Ideas?
Godmar and I think it might be a problem with mulitple readers blocked
on the same file descriptor. Does that sound plausible for your app?
I'll look into it some more...
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
${HOME} is where the .emacs is.
Re: stack overflow interacts poorly with classloaders
Tim Stack wrote:
Preloading in this case means checking if a class references
StackOverflowError or any of its ancestors and then having the class
loader load them in, or we just treat them as "special classes" that
magically resolve to system classes regardless of the class loader.
I'm not sure if that's sufficient. For example this code:
...
try {
wasteLotsofStackSpace();
} catch (SomeAppSpecificException i) {
...
}
...
may still invoke the ClassLoader and call out into Java code in the
exception dispatching path.
The problem is really that the exception dispatch path may wander out
into arbitrary Java code (via loadClass()).
It seems to me that the solution is to make sure that all Class names
referenced in a catch clause are resolved before any code in the
corresponding try block is executed. Can we just get away with making
sure all class names referenced in a catch block are resolved when the
method is compiled?
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
Research is not just an adventure, its a job.
Re: stack overflow interacts poorly with classloaders
Jason Baker wrote: As for classes loaded by the catch body, is this really a problem? Once a StackOverflow has been dispatched, we should be able to throw a new one and make progress. Right, we should only be forcing the load of classes referenced in the catch clause, and not necessarily classes referenced in the body of the catch. Taking Jason's earlier point, I assume the verifier should be doing this. Is that the best place for us to do this? I've not got a clue about the verifier... -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Indifference may cause the downfall of mankind, but who really cares?
Re: porting kaffe on Ecos
I wish to build Kaffe on Ecos. What files do need to be modified or checked? Kaffe works on the OSKit out of the box (well, it will compile at least). Depending on why you want to use Ecos, the OSKit might be sufficient. http://www.cs.utah.edu/flux/oskit/. (I work in the research group that developed the OSKit, and help keep Kaffe and the OSKit in synch, so I'm not an unbiased source of info.) I don't think an Ecos port has been attempted yet. There are porting instructions at: http://www.kaffe.org/porting.html -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] A closed mouth gathers no foot.
Re: C+Java profiling, debugging, and a feedback infrastructure
A while ago I wrote: Thanks to excellent work by Tim Stack of our group at the University of Utah, in support of our work on `Janos', an active networks platform, we've added one major and two auxiliary enhancements to Kaffe: * C+Java cross-language gprof support * C+Java cross-language gdb support * Basic feedback system This code has been checked into the public Kaffe CVS repository. You'll have to reconfigure (see FAQ/FAQ.xprofiling) to use it. You can get more information from the Janos Kaffe page: http://www.cs.utah.edu/flux/janos/kaffe.html This profiler, Xprof, works like gprof; it generates a statistical sample-based profile of time spent in C and Java code. Xprof complements the pre-existing Kaffe profiler which is precise, but only measures Java code. Xprof also requires GNU gprof to generate human-readable output. Xprof currently only works on Linux and FreeBSD x86 boxes when using the unix-jthreads threading system in Kaffe. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "VR Cows are a medium rarely well done." -- someone in c.g.a
Re: Thread.stop()
Jason Baker wrote: Thread.stop is dangerous, but without a process model there is really no alternative. I'm using it to halt infinite loops, which is why I need the stack trace. I'm pretty sure that the official position from Sun is that there is no way to stop uncooperative threads in a JVM. According to Sun, you just restart the whole JVM. Both Godmar and Pat use Thread.stop to implement safe termination, so given that it is part of Kaffe, what should the call do? I don't exactly use Thread.stop() in Janos or Alta. I make sure the target thread is stopped in a clean spot (not in the kernel, or other system code) and then just clean it up with a direct jthread_ call. (Technically, this is just what is *supposed* to happen, neither system completely implements termination of very uncooperative threads.) Godmar's solution is quite similar, I think. The real problem with Thread.stop() is that it can stop threads when they're in places like the GC or in the JAR code, and can leave the VM in an unstable state. If you really need to terminate uncooperative Threads, you're going to have to make sure they're not executing critical JVM code. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This space unintentionally left blank.
Re: Ksem lifetime?
Here's another detail that I've been puzzling over while debugging the beos-native Ksem implementation: when is a Ksem that isn't explicitly destroyed actually destroyed? Is a Ksem's lifetime co-terminal with its "owner", or does it continue existing until explicitly destroyed? Ksems are allocated one per thread, and should live only as long as the thread they're associated with. (Look for ksem in kaffe/kaffevm/threads.c.) I think you know this though, so I wonder if I'm missing the point... There are iLock objects that are dynamically allocated, but the threading system never sees those. I've been assuming all along that each jthread destroys all of the locks that it created itself, prior to invoking jthread_exit. Threads (generally) should not exit while holding locks. While this isn't entirely true (see the concurrent Thread.destory() topic), it shouldn't be the responsibility of the threading layer to clean this up. (We need to fix the VM layer to protect itself.) Is this assumption correct, or should I add code to my threading layer that destroys each of a native thread's semaphores immediately before the thread itself exits? You shouldn't have to do this, as the VM-level threading api cleans up its per-thread Ksems as its threads are destroyed. I only just noticed an interesting side-effect of the way Kaffe uses Ksems is that the "owner" thread is the only thread in the system that will block on its Ksem. Also, the "owner" should never signal on its own Ksem, only the Ksems of other threads. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "You can't have everything. Where would you put it?" -- S. Wright
Re: Design details of Kaffe
The closest you'll get to design docs are the FAQ/FAQ.* files. Also,
there is a little bit of info on porting Kaffe to different systems on
the kaffe.org web page (http://www.kaffe.org/porting.html). However,
it is kinda old, so it might be a bit "stale" in spots...
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
${HOME} is where the .emacs is.
No Subject
Roy Wilson [EMAIL PROTECTED] pointed out to me in private
email that Kaffe starves out threads that are contending for a lock.
(I've attached his sample testcase --- somewhat modified).
This behavior results from Kaffe's lock queues being LIFO. Making the
lock queue FIFO fixes his particular problem. (I've attached the
patch, too.) The patch makes the releaser of a lock wake up the
thread on the tail of the queue vs. the thread on the head of the
queue.
However, Godmar has pointed out to me that Kaffe's current
implementation is within the specification (the spec makes no fairness
or liveness guarantees). Additionally, Kaffe breaks broken code
"faster". If you really want fairness, then you'll have to implement
a queue of some sort above the Java primitives.
Anyone else have thoughts on this (or references to JDC
tips/bugs/documentation)?
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
This signature witticism intentionally left blank.
--8--- TakeResource.Java
class TakeResource {
public static final int HOLD_DELAY = 3000;
public static final int ACQUIRE_DELAY = 1000;
public static final int THREADSTART_DELAY = 1000;
public static void main (String argv[]) {
Resource resource = new Resource();
User[] user = new User[3];
user[0] = new User ("A ", resource);
try { Thread.sleep(THREADSTART_DELAY); }
catch (InterruptedException e){}
user[1] = new User (" B ", resource);
try { Thread.sleep(THREADSTART_DELAY); }
catch (InterruptedException e){}
user[2] = new User (" C", resource);
}
}
class User extends Thread {
private String id;
private Resource resource;
public User (String id, Resource resource) {
this.id = id;
this.resource = resource;
System.out.println ("User " + id + " started");
start();
}
public void run() {
while (true) {
resource.take(id);
try { Thread.sleep(TakeResource.ACQUIRE_DELAY); }
catch (InterruptedException e){}
}
}
}
class Resource {
public synchronized void take (String id) {
System.out.println ("User " + id + " has resource");
try { Thread.sleep(TakeResource.HOLD_DELAY); }
catch (InterruptedException e){}
}
}
--8--- TakeResource.Java
--8--- Patch
Index: kaffe/kaffevm/locks.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/locks.c,v
retrieving revision 1.35
diff -u -r1.35 locks.c
--- kaffe/kaffevm/locks.c 2000/04/12 17:41:06 1.35
+++ kaffe/kaffevm/locks.c 2000/05/15 18:59:11
@@ -248,12 +248,43 @@
* time to tell them.
*/
if (lk-mux != 0) {
+#if 1 /* FAIRQUEUING */
+ /* Special case: a single element list */
+ if (unhand(lk-mux)-nextlk == NULL)
+ {
+ tid = lk-mux;
+ lk-mux = NULL;
+ }
+ else
+ {
+ Hjava_lang_Thread** prevTail;
+
+ prevTail = lk-mux;
+
+ /* while there are still two more on the list */
+ while((unhand(*prevTail)-nextlk != NULL)
+ (unhand(unhand(*prevTail)-nextlk)-nextlk) != NULL) {
+ prevTail = (unhand(*prevTail)-nextlk);
+ }
+
+ tid = unhand(*prevTail)-nextlk;
+ assert(unhand(tid)-nextlk == NULL);
+ unhand(*prevTail)-nextlk = NULL;
+
+ /* lk-mux is head of queue, don't update */
+ }
+
+ lk-holder = NULL;
+ putHeavyLock(lkp, lk);
+ ksemPut((Ksem*)(unhand(tid)-sem));
+#else
tid = lk-mux;
lk-mux = unhand(tid)-nextlk;
unhand(tid)-nextlk = 0;
lk-holder = 0;
putHeavyLock(lkp, lk);
ksemPut((Ksem*)(unhand(tid)-sem));
+#endif
}
/* If someone's waiting to be signaled keep the heavy in place */
else if (lk-cv != 0) {
--8--- Patch
C+Java profiling, debugging, and a feedback infrastructure
Hi, Thanks to excellent work by Tim Stack of our group at the University of Utah, in support of our work on `Janos', an active networks platform, we've added one major and two auxiliary enhancements to Kaffe: * C+Java cross-language gprof support * C+Java cross-language gdb support * Basic feedback system The major work is a system for combined profiling of C and JIT'ed Java code in Kaffe. This makes it possible to produce timing and call graph data covering both languages in a format that can be understood by GNU gprof. The implementation works much like regular C profiling: it gets timing information by regularly sampling the current value of the PC and adds a call to an `mcount'-like function to the beginning of JIT'ed methods. Then, at exit, the profiling data is written out, as well as an assembler file containing symbol information for the JIT'ed code. Finally, the JIT'ed code symbol file and a symbol file created from the Kaffe executable are assembled and fed into gprof to create the output. In addition, we have implemented basic functionality to support cross language debugging in gdb. Cross language debugging simply takes the line debugging information from the Java class and outputs it to an assembler file using the same code the profiler used. Then, while executing in gdb you can assemble the current output file and add the symbols to gdb's current state, allowing it to report the current file/line information for JIT'ed Java code. Finally, we have implemented a basic system for feeding JIT information back into subsequent runs of Kaffe. The feedback system allows Kaffe to save certain bits of state to a file so that it can optimize future runs based on past information. Currently, this is only used for preloading libraries and pre-JIT'ing methods. However, it should be flexible enough to hold more data that can be used to do other tricks. More information, a patch (187K), and a complete Kaffe source distribution (both based on early May, 2000 CVS snapshots) can be found on our Janos Kaffe page: http://www.cs.utah.edu/flux/janos/kaffe.html More information about these additions can be found in the FAQ.xprofiler, FAQ.xdebugging, and FAQ.feedback files (which are also on the web page). Before asking that this stuff get committed to the main tree, we're looking for some feedback on it. So please send any comments to this list, the Janos list ([EMAIL PROTECTED]) or to myself ([EMAIL PROTECTED]) and Tim Stack ([EMAIL PROTECTED]). Tim Stack, our most recent Kaffe wizard at Utah, actually implemented all of this. I'm just announcing it. For those interested in what was actually changed, here is a ChangeLog entry: Tim Stack [EMAIL PROTECTED]: * FAQ/FAQ.xprofiler, FAQ/FAQ.xdebugging, FAQ/FAQ.feedback, kaffe/scripts/kaffexprof.in, kaffe/scripts/nm2as.awk, kaffe/libraries/clib/management/XProfiler.c, kaffe/libraries/javalib/kaffe/management/XProfiler.java, configure.in, kaffe/kaffe/main.c, config/i386/jit3-i386.def, config/i386/freebsd2/md.h, config/i386/linux/md.h, include/Makefile.am, include/Makefile.in, kaffe/Makefile.am, kaffe/Makefile.in, kaffe/kaffe/Makefile.am, kaffe/kaffe/Makefile.in, kaffe/kaffevm/systems/unix-jthreads/Makefile.am, kaffe/kaffevm/Makefile.am, kaffe/kaffevm/Makefile.in, kaffe/kaffevm/jit3/Makefile.am, kaffe/kaffevm/jit3/Makefile.in, kaffe/kaffevm/baseClasses.c, kaffe/kaffevm/classMethod.c, kaffe/kaffevm/external.c, kaffe/kaffevm/external.h, kaffe/kaffevm/jni.c, kaffe/kaffevm/methodCache.c, kaffe/kaffevm/methodCache.h, kaffe/kaffevm/stringSupport.h, kaffe/kaffevm/utf8const.c, kaffe/kaffevm/jit3/machine.c, kaffe/xprof, kaffe/xprof/Makefile.am, kaffe/xprof/Makefile.in, kaffe/xprof/callGraph.h, kaffe/xprof/callGraph.c, kaffe/xprof/debugFile.h, kaffe/xprof/debugFile.c, kaffe/xprof/feedback.h, kaffe/xprof/feedback.c, kaffe/xprof/fileSections.h, kaffe/xprof/fileSections.c, kaffe/xprof/gmonFile.h, kaffe/xprof/gmonFile.c, kaffe/xprof/gmon_out.h, kaffe/xprof/mangle.h, kaffe/xprof/mangle.c, kaffe/xprof/memorySamples.h, kaffe/xprof/memorySamples.c, kaffe/xprof/sectionFile.h, kaffe/xprof/sectionFile.c, kaffe/xprof/xprofiler.h, kaffe/xprof/xprofiler.c: Added/modified to support xprofiling, xdebugging, and feedback. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Indifference may cause the downfall of mankind, but who really cares?
Re: More ksem fun with the beos-native threading system... (fwd)
Odd... I sent this to the ML a couple of weeks ago, but it doesn't seem to have made it out... I didn't see anything... I was hoping the silence meant you'd solved the problem. :) One suggestion I've got for you is that the gc-lock is a "special case" lock, with some gross special case code in getHeavyLock(). That might have something to do with its magic morphing behavior. Though... every getHeavyLock() on the gc lock should find the same address. The last portion shows the relative portions from 'ps', plus some info garnered from a debugger. As the comments indicate, you can see one or more threads either attempt to acquire a ksem they already hold, or release a ksem that they don't hold. Hmm... maybe "ownership" is somehow being misplaced? The scheme for determining ownership of a lock is based on the stack address of the iLock**, and requires that the threading system correctly report the current bounds of the thread's stack (if this is wrong, a thread might erroneously re-acquire a lock if it doesn't think it already owns it.) You could probably test for this by adding a new field to the iLock with the thread id in it, and assert'ing that that is correct... it would be handy if this sort of debugging info could be turned on/off easily too... It seems to me that one or more of the following are true: 1) A trivial mapping of the ksem interface to BeOS counting semaphores doesn't implement the correct ksem semantics. At the very least, the following are unclear to me: - If ksemGet is interrupted by a system call (as opposed to timing out), is it supposed to keep trying to acquire the ksem, or just return "false" ? Three of the four call sites to ksemGet() don't check the return value. You might try assert()'ing they actually get the lock. (I would guess that a timeout of 0 implies that the ksemGet() should retry until it succeeds... I think.) - If ksemGet's timeout argument is non-zero, what is the unit of measurement ? Milliseconds. - Does ksemPut always decrement the ksem's count even if no threads are blocked on the ksem ? ? That way the wakeup is stored in the semaphore for a later thread to come along and use... I'm pretty sure that is the standard semantics. 2) The scheme whereby Kaffe determines whether a lock is being contended or not fails for some reason under certain circumstances. This would happen if the atomic test+set operations aren't defined or aren't actually atomic. Kaffe falls back on a ?: operator in that case... The second one is mere speculation on my part; I'd like to be able to test it using a different OS/threading system, but it looks like only my beos-native threading system has ksems at all (a conclusion arrived at by grepping for "THREAD_SYSTEM_HAS_KSEM") ... You're definetly the first. Sorry. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Does the name `Pavlov' ring a bell?
fixes for java.util.Vector
Here are some fixes for java.util.Vector so that a Vector can be used
through the AbstractList interface. I just added add() and set(),
which was enough to get an app I'm using to work on Kaffe.
(I didn't realize how gross Vector had become when they retrofitted
java.util.AbstractList onto it... most methods are duplicated in the
new Vector.)
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
He who dies with the most toys is still dead.
Index: libraries/javalib/java/util/Vector.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/util/Vector.java,v
retrieving revision 1.15
diff -u -r1.15 Vector.java
--- libraries/javalib/java/util/Vector.java 1999/09/23 18:15:38 1.15
+++ libraries/javalib/java/util/Vector.java 2000/05/08 23:31:53
@@ -172,6 +172,15 @@
return (-1);
}
+public void add ( Object obj, int index) {
+ insertElementAt(obj, index);
+}
+
+public boolean add ( Object obj ) {
+ insertElementAt(obj, size());
+ return true;
+}
+
public synchronized void insertElementAt ( Object obj, int index ) {
if ( elementCount == elementData.length ) {
@@ -248,12 +257,20 @@
elementData[elementCount] = null;
}
-public synchronized void setElementAt(Object obj, int index)
- {
- if (index = elementCount) {
+public Object set ( int index, Object obj ) {
+ Object old;
+
+ if ((index = elementCount) || (index 0)) {
throw new ArrayIndexOutOfBoundsException();
}
+ old = elementData[index];
elementData[index] = obj;
+
+ return old;
+}
+
+public synchronized void setElementAt(Object obj, int index) {
+ set(index, obj);
}
public synchronized void setSize(int newSize) {
java.util.Timer?
I have a class that imports javax.swing.* and java.util.*. It uses a class Timer, expecting to get javax.swing.Timer. When compiling this class against Kaffe's Klasses.jar, jikes complains thusly: Error: Type Timer is imported on demand from package javax/swing and package java/util. What is the class java.util.Timer in Klasses.jar? I don't see it in any of Sun's java documentation, and it only seems to be used by 'java.util.TimerTask' which is also specific to Kaffe as far as I can tell. There's also a kaffe.util.Timer and kaffe.util.TimerClient which look like they do something similar? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "VR Cows are a medium rarely well done." -- someone in c.g.a
Re: A Ksem question [Was: Re: changes to thread locking layer]
Thanks for the backtrace. Looks like all the threads are blocked on different locks (the utilities you've got for querying this stuff are pretty spiffy...). Are the semaphores initialized correctly? I belive the Kaffe locking system requires the semaphores to have an initial value of '1' (e.g., the resource is available). Yours are all at -1, implying they might have started at 0? You might try '-vmdebug SLOWLOCKS' to see if the KaffeVM really is trying to lock the same lock recursively... it doesn't look like its getting beyond the first lock acquire in any thread, though. (BTW, your mailer re-formatted the GDB output, so you might want to watch that in the future.) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "Forty-Two." -- Deep Thought
Mailing list archive out of date
The mailing list archive seems to have stagnated. It doesn't have any messages more recent than April 6. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This space unintentionally left blank.
Re: A Ksem question [Was: Re: changes to thread locking layer]
Archie Cobbs wrote: If it should still be true, how about adding an assert() at the appropriate point in the code? I just looked into this a bit... there's no convenient place to hang the assert. Currently, the locking infrastructure determines the "owner" of a lock by checking if the magic pointer is on the current thread's stack. (Basically we just need to know if the current thread is doing a recursive lock --- in locks.c::slowLockMutex()). An alternative is to put an assert in kaffe/kaffevm/systems/unix-jthreads/jthread.c:jmutex_lock(): assert(lock-holder != jthread_current()); We're already keeping track of ownership information here Actually that code will deadlock a thread if entered it recursively. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "VR Cows are a medium rarely well done." -- someone in c.g.a
Re: ERROR in Kaffe: locks.c
Nandana wrote: When I try to run any java class it gives following error. Do you know when it fails? If you do a '-verbose' run, you can see what class it might be loading. Kaffe: locks.c:147: putHeavyLock: Assertion `*lkp == ((iLock*)-1)' failed. Aborted putHeavyLock() is checking that the lock being "put" is a lock that is actively being gotten and manipulated by the current thread. (All calls to putHeavyLock() are preceeded by a call to getHeavyLock() that sets the lock to LOCKINPROGRESS (which is a #define for -1). Also, you might have some sort of race condition if COMPARE_AND_EXCHANGE or ATOMIC_EXCHANGE and exchange aren't really thread-safe. You might try running with '-vmdebug SLOWLOCKS' to get a trace of the heavy lock behavior. -vmdebug only works if Kaffe is configured with --enable-debug, so you might have to re-configure and re-compile. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] That which does not kill you just didn't try hard enough.
Re: Kaffe having trouble with gnujsp.jar
Stuart Ballard wrote: Would it perhaps be a good idea for configure to print some warnings at the end of the process if "important" stuff like zlib is missing? That, and the run-time shouldn't throw random exceptions. A 'NotImplementedError' or something like that would be much better, especially if it has a nice warning... I'll get around to it, but anyone can feel free to beat me to it. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This bit of signature was randomly selected. Really.
Re: Problem with StringBuffer
I think the actual problem is not in the StringBuffer size, but in the
copy done when the buffer is un-shared; after all, unless the StringBuffer
jump down from 1Mb to 1 byte, a single instance would not be a big problem;
but having many tokens with a lot of wasted memory would be ...
I whipped up a quick patch for this... I tested it so I know that it
doesn't break anything new. However, I don't know if it will fix your
problem. :)
Basically, in the String(StringBuffer) constructor, I copy the
stringbuffer's contents if used + SLOP buffer.length.
For systems that create a string buffer, stringize it, and then throw
away the string buffer, this may introduce an extra copy while only
saving a small amount of memory.
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
Don't hate yourself in the morning -- sleep until noon!
Index: String.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/lang/String.java,v
retrieving revision 1.27
diff -u -u -r1.27 String.java
--- String.java 1999/10/12 02:29:47 1.27
+++ String.java 1999/12/18 23:46:43
@@ -20,6 +20,12 @@
final public class String implements Serializable, Comparable {
+ /**
+* Maximum slop (extra unused chars in the char[]) that
+* will be accepted in a StringBuffer - String conversion.
+*/
+ private static final int STRINGBUFFER_SLOP = 32;
+
// Note: value, offset, and count are not private, because
// StringBuffer uses them for faster access
char[] value;
@@ -52,11 +58,23 @@
public String (StringBuffer sb) {
- // mark this StringBuffer so that it knows we are using it
+ // mark the StringBuffer so that it knows we are using it
sb.isStringized = true;
+
+ if ((sb.used + STRINGBUFFER_SLOP) sb.buffer.length) {
+ value = new char[sb.used];
+ System.arraycopy(sb.buffer, 0,
+value, 0, sb.used);
+ count = sb.used;
- count = sb.used;
- value = sb.buffer;
+ // StringBuffer is free to reuse its buffer again
+ sb.isStringized = false;
+ }
+ else {
+ // Just point directly to the StringBuffer's char[]
+ count = sb.used;
+ value = sb.buffer;
+ }
}
public String( byte[] bytes) {
changes to thread locking layer
I've got a large (45K) patch to Kaffe's locking layers. This patch cleans up the separation between the vm-internal locking and the thread-specific layer locking. It makes the 'sem2posixLock' hack a first class abstraction (a ksem). The threading interface's requirements for locking are documented and, I think, quite a bit simpler. (I sent out an updated FAQ describing these changes a couple of weeks ago). Since the patch is so large, I didn't include it in this message. You can fetch it from: http://www.cs.utah.edu/~tullmann/ksem-diff.txt, Or, I can mail it to anyone who asks. I tested these changes with the OSKit-pthreads port, the unix-jthreads port, Utah's nodeos-thread port, and a little bit with the unix-pthreads port. Since the unix-pthreads stuff didn't work for me before (see my earlier mail from today), I can only report that the patched version has the same problems. :) The only real bug I fixed (if you don't count ugly code as a bug) is that the heavy-weight lock attached to each thread wasn't being destroyed when the thread was, in unix-pthreads, this meant leaking mutexes and condvars. (In unix-jthreads it didn't matter.) One downside to this patch is that the beos-native thread port and the win32 thread ports get even farther out of date. Though, I belive things should be much simpler for the beos port (as it has native semaphore support). Please let me know if there are any problems with the patch. Here's a ChangeLog entry: ChangeLog: Patrick Tullmann [EMAIL PROTECTED]: * FAQ/FAQ.locks: Updated to clearly define the ksem and jmutex interfaces and the boundary between vm locking and threading layer locking. * kaffe/kaffevm/mem/gc-mem.c: include thread.h instead of jthread.h. * kaffe/kaffevm/ksem.h, kaffe/kaffevm/locks.c, kaffe/kaffevm/locks.h, kaffe/kaffevm/Makefile.am: Added ksem.h. Is a cleanup of the sem2posixLock defines and the thread-dependent locking layer. Added comments, removed lots of #if0 and other dead code. Use debug.h macros. * kaffe/kaffevm/thread.c: Use the Ksem abstraction. Destroy the per-thread heavy lock when thread is killed. * kaffe/kaffevm/systems/oskit-pthreads/*: move the lock interfaces into lock-impl.h, add jcondvar_destroy() and jmutex_destroy() methods. * kaffe/kaffevm/systems/unix-jthreads/*: remove unused functions for gettings lists of threads on mutex/cvs. Remove dead support code for those functions. Add jmutex_destroy() and jcondvar_destroy(). Move lock interfaces into lock-impl.h, out of jthread.h. Clean up lock-impl.h to match new ksem interfaces. * kaffe/kaffevm/systems/unix-pthreads/*: Use the jmutex_ and jcondvar_ interfaces for locking, remove lots of macro layers. Remove redundant per-native-thread lock infrastructure. (Its is redundant with the per-thread ksem managed in kaffevm/thread.c). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Your research fills a much needed gap.
Re: patch for a verbose -fullversion
Alexandre Oliva wrote: If you want this file to be updated every time you compile, you can hack your local copy of Kaffe to do it. No problem. The local hacks are much smaller now. :) Thanks! Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "I'd kill for a Nobel Peace Prize." -- S. Wright
kjc update
About the update to KJC 1.4C. Edouard Parmelan had put some other bug fixes into Kaffe's KJC snapshot (i.e., we were running KJC 1.4B++). See http://rufus.w3.org/tools/Kaffe/messages/5828.html: I just commit kjc-1.4B-egp1 in kaffe CVS Tree. This version of kjc is also mirrored at http://egp.free.fr/kaffe. The KJC 1.4C snapshot that just got checked in still has the do-while bug that I reported a while ago (see http://rufus.w3.org/tools/Kaffe/messages/5820.html). I don't know which broken version is better. :) Hopefully the KJC folks will have another official release soon. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "VR Cows are a medium rarely well done." -- someone in c.g.a
Re: patch for a verbose -fullversion
I updated my '-fullversion' patch to meet most of Alexandre's
suggestions and fixes. It is below.
Alexandre Oliva wrote:
I don't like having phony targets that cause something to be built
every time I run `make'.
Its somewhat annoying, but in reality the generation and recompile are
lost in the shuffle of symbol extraction and relinking. I really
wanted compile-time information (such as the date and the actual flags
used) to be part of the version header. Short of having GCC or the
linker generate this info, I don't see another choice hmm, we
could stuff it KaffeS.c which gets recompiled for each link
You could extract the first line of ChangeLog like this:
Done. I also did the '-rm' thing and used a temp file for the
output.
For those who are curious, here's a sample of 'kaffe -fullversion':
Kaffe Virtual Machine
Copyright (c) 1996-2000
Transvirtual Technologies, Inc. All rights reserved
Engine: Just-in-time v3 Version: 1.0.5 Java Version: 1.1
Configuration/Compilation options:
Compile date : Mon Mar 13 16:53:15 MST 2000
Compile host : alta.cs.utah.edu
Install prefix: /n/alta/z/tullmann/janos/install/kaffe-1.1-kaffe-jit-debug-unix
Thread system : unix-jthreads
CC: gcc
CFLAGS: -g -O2 -Wall -Wstrict-prototypes
LDFLAGS : -export-dynamic
ChangeLog head: Mon Mar 13 15:23:44 PST 2000 Archie Cobbs [EMAIL PROTECTED]
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
Your research fills a much needed gap.
Index: kaffe/kaffe/version.c
===
--- /dev/null Mon Mar 13 17:21:36 2000
+++ kaffe/kaffe/version.c Mon Mar 13 16:31:51 2000
@@ -0,0 +1,48 @@
+/*
+ * version.c
+ *
+ * Copyright (c) 2000 The University of Utah. All rights Reserved.
+ *
+ * This file is distributed as is under the terms of the GNU General
+ * Public License.
+ */
+
+/* Print out the Kaffe version information.
+ * This is in a separate file because the version-info.h header file is
+ * re-generated for each compile, and this minimizes the dependencies.
+ */
+#include "config.h"
+#include "config-std.h"
+#include "version.h"
+#include "version-info.h" /* generated at compile time */
+
+extern char* engine_name; /* defined in the engine's library */
+extern char* engine_version; /* defined in the engine's library */
+
+static FILE* versionfd = stderr;
+
+void
+printShortVersion(void)
+{
+ fprintf(versionfd, "Kaffe Virtual Machine\n");
+ fprintf(versionfd, "Copyright (c) 1996-2000\nTransvirtual Technologies, Inc.
+All rights reserved\n");
+ fprintf(versionfd, "Engine: %s Version: %s Java Version: %s\n",
+ engine_name, engine_version, JAVA_VERSION_STRING);
+}
+
+void
+printFullVersion(void)
+{
+ printShortVersion();
+ fprintf(versionfd, "Configuration/Compilation options:\n");
+ fprintf(versionfd, " Compile date : %s\n", VER_COMPILE_DATE);
+ fprintf(versionfd, " Compile host : %s\n", VER_COMPILE_HOST);
+ fprintf(versionfd, " Install prefix: %s\n", VER_PREFIX);
+ fprintf(versionfd, " Thread system : %s\n", VER_THREAD_SYSTEM);
+ fprintf(versionfd, " CC: %s\n", VER_CC);
+ fprintf(versionfd, " CFLAGS: %s\n", VER_CFLAGS);
+ fprintf(versionfd, " LDFLAGS : %s\n", VER_LDFLAGS);
+ fprintf(versionfd, " ChangeLog head: %s\n", VER_CHANGELOG_HEAD);
+ // fprintf(versionfd, " Libraries : %s\n", VER_KAFFELIBS);
+}
+
Index: kaffe/kaffe/version.h
===
--- /dev/null Mon Mar 13 17:21:36 2000
+++ kaffe/kaffe/version.h Thu Mar 9 18:12:08 2000
@@ -0,0 +1,29 @@
+/*
+ * version.h
+ *
+ * Copyright (c) 2000 The University of Utah. All rights Reserved.
+ *
+ * This file is distributed as is under the terms of the GNU General
+ * Public License.
+ */
+
+#ifndef KAFFE_KAFFE_VERSION_H
+#define KAFFE_KAFFE_VERSION_H
+
+#define JAVA_VERSION_STRING"1.1"
+#define JAVA_VERSION_HEX 0x00010001
+
+/*
+ * Print copyright notice and simple version info (Java version,
+ * engine type, etc). Prints to stderr.
+ */
+void printShortVersion(void);
+
+/*
+ * In addition to the short version, print ludicrous amounts of
+ * information about the compile environment, configuration
+ * options, etc.
+ */
+void printFullVersion(void);
+
+#endif /* KAFFE_KAFFE_VERSION_H */
Index: kaffe/kaffe/Makefile.am
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffe/Makefile.am,v
retrieving revision 1.5
diff -u -u -r1.5 Makefile.am
--- kaffe/kaffe/Makefile.am 1999/02/08 10:44:38 1.5
+++ kaffe/kaffe/Makefile.am 1999/12/03 06:45:20
@@ -10,10 +10,35 @@
INCLUDES = -I../kaffevm -I$(srcdir)/../kaffevm -I$(top_srcdir)/libltdl
-Kaffe_SOURCES = main.c
simple patch for config-std.h
Here's a simple cleanup patch for Kaffe's config/config-std.h. It uses __'s in the __NORETURN__ magic, and adds similar magic, __UNUSED__, for unused functions (useful for static inline methods). A ChangeLog entry might look like: Patrick Tullmann [EMAIL PROTECTED] * config/config-std.h: clean namespace in __NORETURN__. Add __UNUSED__ magic for __attribute__((__unused__)). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Index: config/config-std.h === RCS file: /cvs/kaffe/kaffe/config/config-std.h,v retrieving revision 1.4 diff -u -r1.4 config-std.h --- config/config-std.h 1999/02/03 01:55:04 1.4 +++ config/config-std.h 2000/03/09 21:30:56 @@ -48,9 +48,16 @@ #undef __NORETURN__ #if defined(__GNUC__) -#define__NORETURN__ __attribute__((noreturn)) +#define__NORETURN__ __attribute__((__noreturn__)) #else #define__NORETURN__ +#endif + +#undef __UNUSED__ +#if defined(__GNUC__) +#define__UNUSED__ __attribute__((__unused__)) +#else +#define__UNUSED__ #endif /* SunOS has on_exit only */
patch kaffe main.c for 2000
(I'm trying to clean up my local hacks on the Kaffe tree, thus the
forthcoming sequence of bizarre little patches.)
This patch brings the -version printed copyright notice in main.c up
into the new millennium. Doesn't need much of a ChangeLog entry,
methinks (alternatively, whomever checks it in can take credit.)
Heh, my first Y2K fix. :)
-Pat
Index: kaffe/kaffe/main.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffe/main.c,v
retrieving revision 1.27
diff -u -r1.27 main.c
--- kaffe/kaffe/main.c 2000/01/28 23:21:46 1.27
+++ kaffe/kaffe/main.c 2000/03/09 21:37:05
@@ -232,7 +232,7 @@
}
else if (strcmp(argv[i], "-version") == 0) {
fprintf(stderr, "Kaffe Virtual Machine\n");
- fprintf(stderr, "Copyright (c) 1996-1999\nTransvirtual
Technologies, Inc. All rights reserved\n");
+ fprintf(stderr, "Copyright (c) 1996-2000\nTransvirtual
+Technologies, Inc. All rights reserved\n");
fprintf(stderr, "Engine: %s Version: %s Java Version:
%s\n", engine_name, engine_version, java_version);
exit(0);
}
patch for debug and classpath stuff
The attached patch cleans up some of the -vmdebug debugging
infrastructure in Kaffe, though only a little. Specifically, I
renamed VMLOCKS to SLOWLOCKS, and updated findInJar to the use the
-vmdebug-style magic. VMLOCKS is currently unused, and SLOWLOCKS
makes more sense (and will be used in a forthcoming patch... :)
ChangeLog entry:
Patrick Tullmann [EMAIL PROTECTED]
* kaffe/kaffevm/debug.[ch]: drop DBG_VMLOCKS, add
DBG_SLOWLOCKS, DBG_INITCLASSPATH and DBG_CLASSLOOKUP flags.
* kaffe/kaffevm/findInJar.c: drop old-style debugging, use
DBG_INITCLASSPATH and DBG_CLASSLOOKUP for debugging rumaging
around in jar files.
-Pat
Index: kaffe/kaffevm/debug.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/debug.c,v
retrieving revision 1.27
diff -u -r1.27 debug.c
--- kaffe/kaffevm/debug.c 2000/02/03 18:27:53 1.27
+++ kaffe/kaffevm/debug.c 2000/03/09 21:46:23
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 1999 The University of Utah. All rights reserved.
+ * Copyright (c) 1998, 1999, 2000 The University of Utah. All rights reserved.
*
* See the file "license.terms" for information on usage and redistribution
* of this file.
@@ -61,7 +61,7 @@
/* XXX Clean these names up, re-order them and make them consistent. */
#define D(name, str) { #name, DBG_ ## name, str }
D(NONE, "Nothing"),
- D(VMLOCKS, "Mutex lock/unlock operations called by VM"),
+ D(SLOWLOCKS, "Heavy lock/unlock operations"),
D(VMCONDS, "Show condition variable operations called by VM"),
D(NEWINSTR, "Show softnew_ instructions (NEW, NEWARRAY, ANEWARRAY)"),
D(VMTHREAD, "Show some java.lang.Thread operations called by VM"),
@@ -71,6 +71,7 @@
D(EXCEPTION, "Debug exceptions, don't catch traps"),
D(STACKTRACE, "Debug stack trace inspection"),
D(INIT, "Show initialization steps."),
+ D(INITCLASSPATH, "Show classpath initialization."),
D(BREAKONEXIT, "Cause an exception before exiting. (Useful under GDB)"),
D(GCPRIM, "Debug gc_primitive_*"),
D(GCALLOC, "Debug gc_heap_alloc*"),
@@ -93,9 +94,10 @@
D(INT_RETURN, "Show return from function. (interpreter)"),
D(INT_VMCALL, "Show call to virtualMachine. (interpreter)"),
D(INT_CHECKS, "Show various checks. (interpreter)"),
- D(ELOOKUP, "Debug exception lookup"),
- D(FLOOKUP, "Debug field lookup"),
- D(MLOOKUP, "Debug method lookup"),
+ D(ELOOKUP, "Debug exception lookup."),
+ D(FLOOKUP, "Debug field lookup."),
+ D(MLOOKUP, "Debug method lookup."),
+ D(CLASSLOOKUP, "Debug class lookup."),
D(JIT, "Debug JIT compiler--show emitted instructions."),
D(MOREJIT, "Debug JIT compiler--show callinfo."),
D(NOGC, "Turn garbage collection off."),
@@ -129,7 +131,7 @@
{ "gcj", DBG_GCJ|DBG_GCJMORE,
"Debug GCJ support in detailed" },
- { "thread", DBG_JTHREAD|DBG_VMLOCKS|DBG_VMCONDS,
+ { "thread", DBG_JTHREAD|DBG_SLOWLOCKS|DBG_VMCONDS,
"Thread operations and locking operations" },
{ "intrp", DBG_INT_NATIVE|DBG_INT_RETURN|DBG_INT_VMCALL,
Index: kaffe/kaffevm/debug.h
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/debug.h,v
retrieving revision 1.24
diff -u -r1.24 debug.h
--- kaffe/kaffevm/debug.h 2000/01/28 23:21:46 1.24
+++ kaffe/kaffevm/debug.h 2000/03/09 21:46:23
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 1999 The University of Utah. All rights reserved.
+ * Copyright (c) 1998, 1999, 2000 The University of Utah. All rights reserved.
*
* See the file "license.terms" for information on usage and redistribution
* of this file.
@@ -41,7 +41,7 @@
/* Debug Masks: (1 bit per option) */
# define DBG_BIT(x) (((jlong)1)x)
# define DBG_NONE (0)
-# define DBG_VMLOCKSDBG_BIT(0)
+# define DBG_SLOWLOCKS DBG_BIT(0)
# define DBG_VMCONDS DBG_BIT(1)
# define DBG_NEWINSTR DBG_BIT(2)
# define DBG_VMTHREAD DBG_BIT(3)
@@ -101,6 +101,8 @@
# define DBG_SLACKANAL DBG_BIT(52)
# define DBG_GCJ DBG_BIT(53)
# define DBG_GCJMORE DBG_BIT(54)
+# define DBG_INITCLASSPATH DBG_BIT(55)
+# define DBG_CLASSLOOKUPDBG_BIT(56)
# define DBG_ALL ((jlong)(-1))
# define DBG_ANYDBG_ALL
Index: kaffe/kaffevm/findInJar.c
patch for a verbose -fullversion
The following patch (two new files and a patch) adds a '-fullversion'
option to Kaffe that includes the compile date, compile host, a bunch
of compile-time flags, and other interesting compile/link-time
information. (Anyone wanna add a bit to include the first line of the
ChangeLog?) Makes it nice to figure out exactly what version of Kaffe
you're using... (I tend to have a couple versions lying around). It
works by creating a version-info.h header file each time kaffe is
compiled.
One problem with this patch is that I probably didn't do the
Makefile.am stuff quite right. It certainly works for me, but I'm not
sure if I'm abusing some features.
The patch is in two parts: two new file (kaffe/kaffe/version.[ch]) and a
patch against kaffe/kaffe/Makefile.am and kaffe/kaffe/main.c.
Here's a ChangeLog entry:
Patrick Tullmann [EMAIL PROTECTED]
* kaffe/kaffe/version.[ch]: added. Provide the output for
-version and -fullversion.
* kaffe/kaffe/{Makefile.am,main.c}: Add the -fullversion
option, build a version-info.h header file each time Kaffe
is compiled.
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
He who dies with the most toys is still dead.
kaffe/kaffe/version.c:
/*
* version.c
*
* Copyright (c) 2000 The University of Utah. All rights Reserved.
*
* This file is distributed as is under the terms of the GNU General
* Public License.
*/
/* Print out the Kaffe version information.
* This is in a separate file because the version-info.h header file is
* re-generated for each compile, and this minimizes the dependencies.
*/
#include "config.h"
#include "config-std.h"
#include "version.h"
#include "version-info.h" /* generated at compile time */
extern char* engine_name; /* defined in the engine's library */
extern char* engine_version;/* defined in the engine's library */
static FILE* versionfd = stderr;
void
printShortVersion(void)
{
fprintf(versionfd, "Kaffe Virtual Machine\n");
fprintf(versionfd, "Copyright (c) 1996-2000\nTransvirtual Technologies, Inc.
All rights reserved\n");
fprintf(versionfd, "Engine: %s Version: %s Java Version: %s\n",
engine_name, engine_version, JAVA_VERSION_STRING);
}
void
printFullVersion(void)
{
printShortVersion();
fprintf(versionfd, "Configuration/Compilation options:\n");
fprintf(versionfd, " Compile date : %s\n", VER_COMPILE_DATE);
fprintf(versionfd, " Compile host : %s\n", VER_COMPILE_HOST);
fprintf(versionfd, " Install prefix: %s\n", VER_PREFIX);
fprintf(versionfd, " Thread system : %s\n", VER_THREAD_SYSTEM);
fprintf(versionfd, " CC: %s\n", VER_CC);
fprintf(versionfd, " CFLAGS: %s\n", VER_CFLAGS);
// fprintf(versionfd, " Libraries : %s\n", VER_KAFFELIBS);
}
kaffe/kaffe/version.h:
/*
* version.h
*
* Copyright (c) 2000 The University of Utah. All rights Reserved.
*
* This file is distributed as is under the terms of the GNU General
* Public License.
*/
#ifndef KAFFE_KAFFE_VERSION_H
#define KAFFE_KAFFE_VERSION_H
#define JAVA_VERSION_STRING "1.1"
#define JAVA_VERSION_HEX0x00010001
/*
* Print copyright notice and simple version info (Java version,
* engine type, etc). Prints to stderr.
*/
void printShortVersion(void);
/*
* In addition to the short version, print ludicrous amounts of
* information about the compile environment, configuration
* options, etc.
*/
void printFullVersion(void);
#endif /* KAFFE_KAFFE_VERSION_H */
The patch:
Index: kaffe/kaffe/Makefile.am
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffe/Makefile.am,v
retrieving revision 1.5
diff -u -r1.5 Makefile.am
--- kaffe/kaffe/Makefile.am 1999/02/08 10:44:38 1.5
+++ kaffe/kaffe/Makefile.am 2000/03/10 05:52:05
@@ -10,10 +10,32 @@
INCLUDES = -I../kaffevm -I$(srcdir)/../kaffevm -I$(top_srcdir)/libltdl
-Kaffe_SOURCES = main.c
+Kaffe_SOURCES = main.c version.o
LIBKAFFEVM = ../kaffevm/libkaffevm.la
Kaffe_LDFLAGS = -export-dynamic
Kaffe_LDADD = $(DLOPEN_JAVA_LIBS) $(LIBKAFFEVM) $(KAFFE_LIBS)
Kaffe_DEPENDENCIES = $(LIBKAFFEVM) $(JAVA_LIBS)
+
+### Rules to generate the version-info header file
+
+version.d: version-info
+
+version.o: version-info
+
+version-info:
+ rm -f version-info.h
+ echo "/* version-info.h is automagically generated by kaffe Makefile */"
+version-info.h
+ echo '#define VER_COMPILE_DATE "'`date`'" ' version-info.h
+ echo '#define VER_COMPILE_HOST "'`hostname`'"' version-info.h
+ echo '#define
Re: Nightly regression tests
Building 'Klasses.jar' is now part of the "build" test, and won't show up explicitly unless something goes wrong. The tests are run against the newly compiled Klasses.jar. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "VR Cows are a medium rarely well done." -- someone in c.g.a
Re: Nightly regression tests
Pavel Roskin wrote: hmtl - html Oops. I should run my email through a regression test... :) I think that it only makes sense to send a report if it has changed. Perhaps you could send a diff and a comment saying where to find the complete report. The summary at the top of the report is supposed to encapsulate that sort of information (i.e., what has changed since last time)... Internally, I just delete the report every morning after glancing at the summary (assuming the summary hasn't changed). I can see that there are issues if you have to dl your mail and don't want to pay for big reports. In my experience (with a local email connect) there is no cost to bigger reports with a summary at the top. If you do so, I don't think that there will be more that one report per week. Maybe you could simply send reports to this list. We do have support for weekly-only mailings in Flest (the test infrastructure). That just means you only get Friday's report. If folks are interested in this, I can certainly add it. I don't think making an automated weekly mail part of the kaffe list is the right thing, though. Please don't forget to recompile all java classes. If a java source file is broken, I want to get the report immediately, and not after rebuilding Klasses.jar Excellent idea, I'll add that to the build test. How about --with-threads=unix-pthreads? But probably FreeBSD doesn't support it yet :-( Nope, no FreeBSD port yet. Testing on a Linux box is a possibility, but I'm not convinced the incremental improvement in testing is worth the effort on our end. But, a FreeBSD port of unix-pthreads would definetly go in. Anyway, thank you for your efforts! No problem. Thanks for the suggestions, Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This bit of signature was randomly selected. Really.
Re: state of the developer tools?
Archie Cobbs wrote: Should I not be expecting my generated Makefile.in's to match those in the repository? Is there a v1.4-a2 or something? Though Alexandre's should work. Attached is the version I use. Thanks, that's a bit closer. The aclocal from 1.4a-dep also seems to be out of sync with what Kaffe has checked in, too. Also, in addition to the raw perl script, I'd probably need a bunch of updated files from share/aclocal and share/automake. Is the CVS version of automake still missing features that Kaffe requires, or could we all synchronize on that? Could an updated snapshot of "Alexandre's" automake source tree be put somewhere? I'm trying to make sure my tools are as in sync with the rest of the developers as possible. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This bit of signature was randomly selected. Really.
Re: state of the developer tools?
Dunno, I haven't tested it lately. If you give it a try and it works for you, just `make dist' it (automake CVS) and let us know. I tried it out and it works (as well as I can tell). I looked over the Makefile.in diffs, and there are some bug fixes, but it doesn't look like there should be any problems. aclocal.m4 also has a bunch of additions to it. I put a snapshot at http://www.cs.utah.edu/~tullmann/download/automake-1.4a-2227.tar.gz I'm going to try maintaining a web page for the "approved" Kaffe developer tools: http://www.cs.utah.edu/~tullmann/kaffetools.html Incidentally, http://www.kaffe.org/develop.html should probably be updated with the info on kaffetools.html, or just point to it. (It says automake-1.4 will work). I've also tried the CVS version of autoconf, which requires some dramatic changes to configure.in, so I say we stay away from that. v2.13 works just fine. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Success means never having to wear a suit.
cleaning up the locking layers
ay around this restriction, but if don't know what it is, you probably shouldn't try it. XXX How many of the internal locks really need to be recursive? Threading System Synchronization Primitives === The VM-internal locking scheme is implemented on top of the primitives provided by the Kaffe threading system. The underlying threading system has two choices for implementing the lowest layer of locking in Kaffe. First is the Ksem interface which provides a semaphore primitive on which the Kaffe run-time bases its "heavy locks". (See the "Kaffe Fast Locking" section below.) The second option is to implement the "jmutex/jcondvar" interface (which is just used to fill out a default Ksem implementation.) A. The Ksem interface: - files: kaffe/kaffevm/ksem.h, threading system lock files types: Ksem ksemInit(sem) ksemGet(sem,timeout) ksemPut(sem) The Ksem is a binary semaphore, and need not be recursive. The Ksem is initialized to 0 (in semaphore-speak this means the resource is not available). ksemGet() can timeout, thus it returns a boolean indication of whether it acquired the semaphore or not. As a side-effect of Kaffe's fast locking scheme, there is a one-to-one mapping between Ksem and threads. Also, all Ksem's are dynamically allocated, and all are initialized before being used. B. The jmutex/jcondvar interface: files: kaffe/kaffevm/ksem.h, threading system lock files types: jmutex, jcondvar jmutex_lock jmutex_unlock jcondvar_signal jcondvar_wait At this layer, mutexes are distinct from condition variables, though the condition variable interface is provided with the associated mutex. A jmutex should not be recursive. Kaffe guarantees that a jmutex and jcondvar are used in a strict pair (see the implementation of Ksem). Broadcast is never used on the condvar. Kaffe Fast Locking == Kaffe has a fast locking scheme that minimizes the cost of uncontended locks. The fast locking scheme is implemented between VM-internal locking layer and the threading system's locking primitives. The basic idea is that a "heavy" lock is not allocated unless there is some contention for it. Additionally, another trick is used to avoid maintaining extraneous state for recursive locks. The Kaffe Fast Locking scheme takes advantage of several observations. First, all lockable objects have a pointer to a heavy lock, in case one is needed for the object. Second, all pointers to heap-allocated objects in Kaffe are at least 4-byte aligned, thus making the bottom two bits of every pointer available. Third, if a recursive lock is re-acquired by the same thread, it is necessairly acquired in a more recent stack frame (i.e., the frame in which the lock was originally acquired is still on the stack). The recursion optimization can be considered separately from the fast lock acquistion. Here is some weak pseudo-code to explain the algorithm. if lock field is NULL set lock field to current thread's "id". else /* lock field is a pointer */ if lock field bottom bit is set /* lock field points to a heavy lock */ ... else /* lock field points to some thread's "id" */ allocate a heavy lock and set the lock field to address of heavy lock This must all be done atomically. Kaffe gets around this requirement by chaining atomic compare-and-swap operations and by swapping the magic value LOCKINPROGRESS into the field. The common case requires a single atomic compare and swap. The "id" is where the recursive lock optimization comes in. The id is actually the address of a local stack slot in the function that invoked "lockMutex". This is used to decide if a thread owns a lock (if the address doesn't fall on its stack, then the thread cannot own the lock) and is used to optimize recursive locks (if the address is on the current thread's stack, then it must be from a previous stack frame). This is why the iLock variable must be allocated as an automatic variable on the stack frame. Jason Baker [EMAIL PROTECTED] Jun 29, 1999 updated by Alexandre Oliva [EMAIL PROTECTED] Sept 18, 1999 updated by Patrick Tullmann [EMAIL PROTECTED] Feb 25, 2000
Re: cleaning up the locking layers
Godmar Back wrote: NOTE: these are functions, and must remain so, since their addresses are taken in some engines. Is that a change you're proposing? Currently, the address of the slowLock/Unlock functions is taken in the jit3 engine; it's inlined in the code the jit emits. Or do you mean something else? That was already in the FAQ, so I kept it... I assume its still true of the older JIT engine? I'll look into it an see what the real story is. It's also not clear to me how useful it would be to tweak lockObject (or even slowLockObject) to log execution of monenter/exit: all inlined uncontended acquisitions would not be logged in this case.Might still be partially useful though. Again, previous text. Its a good abstraction in any event. If you define Ksem in kaffevm/ksem.h, does that mean that a threading system cannot implement Ksem's operations as macros? Currently I have the Ksem typedef and the ksemInit/ksemPut/ksemGet functions as static inline methods in ksem.h. The entire set is surrounded by #ifndef JTHREAD_HAS_KSEM. So, a threading system should be able to implement ksemPut and ksemGet as macros or inline functions. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Don't hate yourself in the morning -- sleep until noon!
Kaffe requires -g
Building kaffe requires that the '-g' flag be passed to gcc. Otherwise, you get a very broken executable. This is a long-standing problem... though I can't find any metion of it in the mailing list archive... I could have sworn this came up in the past. Something to do with sysdepCallMethod not being compiled correctly without -g... anyway... My real bug report, though, is that configure does not enforce this. Currently Kaffe relies on autoconf defaulting CFLAGS to '-g -O2'. If CFLAGS is set in the environment when Kaffe is compiled, the -g is dropped, and the resulting Kaffe builds, but won't run. I suggest: # Kaffe doesn't run without the -g: CFLAGS="$CFLAGS -g" right at the top of configure.in -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] He who dies with the most toys is still dead.
patch for update-class-list
This patch prevents developers/update-class-list from including /.~foo.java (i.e., temporary backup files) in the list of classes to include in Klasses.jar. Hmm... I guess most folks don't write their backup files as .~foo..., but it shouldn't cause any problems (files that start with "." probably aren't legal anyway). -Pat diff -u -u -r1.3 update-class-list --- update-class-list 1999/08/06 23:55:36 1.3 +++ update-class-list 2000/02/23 19:12:34 @@ -20,7 +20,7 @@ trap 'rm -f classlist pkglist macrodef; exit 1' 1 2 15 echo WARNING: Omitting java/awt/win32 package from the list of packages -find $SRCDIRS -name \*.java -print | sort classlist +find $SRCDIRS -name ".*" -o -name \*.java -print | sort classlist sed 's,/[^/]*$,,' classlist | uniq | grep -v java/awt/win32 pkglist
Re: patch for update-class-list
find $SRCDIRS -name ".*" -o -name \*.java -print | sort classlist and find $SRCDIRS -name \*.java -a \! -name ".*" -print | sort classlist are the same because the -o has lower precendence. My version is effectively (name ".*" and do nothing) or (name "*.java" and print). Short-circuit evaluation means the second expression isn't tried if the first matches. Yours is a bit more direct (and readable), but requires more escaped magical characters... Hmm, come to think of it yours is much cleaner. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] He who dies with the most toys is still dead.
state of the developer tools?
What are the required autoconf/automake versions for playing with the Kaffe makefiles? autoconf 2.13 seems to work. (the latest CVS autoconf complains a lot, however). I tried automake v1.4, Alexandre's automake-1.4a-dep (from FAQ.automake), and the latest CVS automake. All versions give me a warning in test/regression/Makefile.am, and all generate Makefile.ins that are non-trivially different from those that are checked into the repository. Should I not be expecting my generated Makefile.in's to match those in the repository? Is there a v1.4-a2 or something? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "You can't have everything. Where would you put it?" -- S. Wright
bug in libltdl/ltdl.c
Cross-compiling Kaffe for the OSKit I get: libltdl/ltdl.c: In function `load_deplibs': libltdl/ltdl.c:1199: `shlib_ext' undeclared (first use this function) The definition of shlib_ext is ifdef LTDL_SHLIB_EXT'd at the top of the file. This code is part of some recent (Feb 15th) changes. I couldn't tell you why LTDL_SHLIB_EXT isn't defined on the OSKit (though I'll guess its because I never enabled the OSKit's dynamic library loading support). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Success means never having to wear a suit.
kaffe configure bug
Kaffe's configure script resets 'cross_compiling' in the GCJ option test code. Some background (as I understand things): Kaffe's configure script is supposed to honor the KAFFEH environment variable if Kaffe is being cross-compiled (it uses KAFFEH instead of the cross-compiled kaffeh to build .h files). The configure script checks the 'cross_compiling' variable to determine this. The OSKit config.frag explicitly sets 'cross_compiling'. The problem is that the GCJ configure test magic is unsetting 'cross_compiling' for some reason (the AC_PROG_CXX?). If I configure for the OSKit with '--disable-gcj' then the compile proceeds just fine (it uses $KAFFEH), if I do not explicitly disable GCJ support, the magic in that part of configure.in ends up unsetting cross_compiling, and I can't build Kaffe. I'm not sure what the real problem is, or how to fix it. I don't have a problem disabling GCJ support, just a heads up. I do not know if other cross-compiler envs have this problem. This is from an early February Kaffe CVS snapshot. I haven't upgraded (and won't) because I understand that recent libtool changes break Kaffe on FreeBSD. I tried to submit a bug report but the submission bounced. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Your research fills a much needed gap.
Re: Interfaces
Derek L Davies wrote: But JavaVM is a singleton as well and does have a 'this' pointer. I guess maybe it's not really necessary in JavaVM then either, but was included anyway? Its always easier to wrap a flexible interface an present it as a less flexible one, so I suggest going with the 'this' pointer approach. If it turns out that all the JVMDI code in the world is written to the singleton, no-this-pointer approach it should be pretty easy to wrap. Going the other way is much harder, I think. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Not many people realize just how well known I am -- Anonymous
Re: large Class.forName() patch
Jason Baker wrote:
./developers/fixup.c:addSymbol("_Jv_intClass", CLASS, "int", "", "");
That code is actually commented out already. Godmar will have to
chime in on its intent.
./kaffe/kaffevm/itypes.c: initPrimClass(intClass, "int", 'I', 4);
I suggest using some completely bogus, yet human-readable name in this
context. The primitive types should never be looked up by name, so
"[int]" or ";primitive int" or ... hmm, looking in the VM spec (for
invalid name ideas), I noticed actually it says in S2.2 Identifiers:
"An identifier must not be ... a keyword in the Java programming
language." So, maybe a class with name 'int' is bogus Something
that most JVMs don't seem to check, it seems.
./libraries/javalib/java/lang/Integer.java: final public static Class TYPE =
Class.getPrimitiveClass("int");
As Jason pointed out, this is an internal hack for Kaffe. The
argument could just as easily be Class.PRIMITIVE_INT_MAGIC
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
That which does not kill you just didn't try hard enough.
Re: building kaffeh when cross-compiling
Alexandre Oliva wrote: On Jan 7, 2000, Patrick Tullmann [EMAIL PROTECTED] wrote: Kaffeh is built when cross-compiling Kaffe. Oops. That really isn't a bug (there are cross-builds where you'll want to have a kaffeh). However, my problem is that kaffeh won't link when compiled on the OSKit. There are two solutions that I see: (1) fix kaffeh (that means invoking the platform-specific INIT_MD() stuff) or (2) prevent kaffeh from being built (3) fix the OSKit so that it doesn't have these link problems. Fixing kaffeh seems silly since it will never be used in my cross-build environment. I just need a simple hack to prevent kaffeh from being built at all... I mistakenly assumed the locally-installed-kaffeh hack could do that, but I see that it shouldn't. Ah, well. If someone feels like implementing --without-kaffeh, I'd appreciate it. :) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "You can't have everything. Where would you put it?" -- S. Wright
building kaffeh when cross-compiling
Kaffeh is built when cross-compiling Kaffe. There is some magic in configure that tries to only build kaffeh if kaffe is not being cross-compiled. It sets things up so that kaffeh will be built through a magic rule in include/Makefile.am (stamp-h0all). However, kaffeh is built by default, anyway! I think the problem is that kaffe/Makefile.am includes 'kaffeh' on the list of SUBDIRS. I'm not sure if there are other ramifications of removing kaffeh from the Makefile.am SUBDIRS, though. I submitted a bug (#607) before I realized that Kaffe's makefiles were trying to do the right thing. (The database system won't let me add any NOTEs or anything to the bug to include this update...) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "I'd kill for a Nobel Peace Prize." -- S. Wright
class resolution deadlock
FYI, my patch to fix the deadlock in classMethod.c:resolveString() hasn't been applied. I think folks assume that since I'm at the Univ. of Utah, I've got write access to the repository... :) None of the relevant files have changed, so the old patch should still be good: http://rufus.w3.org/tools/Kaffe/messages/5598.html There's also a regression test: http://rufus.w3.org/tools/Kaffe/messages/5586.html -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Not many people realize just how well known I am -- Anonymous
Re: install errors
Alexandre Oliva wrote: Please give it one more try, I've just fixed the libtool bug that was causing the weirdness at install time. Yep. Seems to be all better now. Thanks! Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "I'd kill for a Nobel Peace Prize." -- S. Wright
Re: install errors
What do you mean when the tree is clean? You can't install from a clean tree because there's nothing to install... ? 'make clean all install' works. (I meant the tree got cleaned immediately before an all install.) If I don't clean the libraries/clib/ directory before doing a 'make all install', I get the error. Doing a 'make -C XXX/libraries/clib/ clean' does something magical so that 'make all install' works. I tried manually removing the offending .la files to see if that would make it work, but it didn't help. I build in a separate tree as well by the way... generally by doing configure, then saying "gmake" then "gmake install". I usually do 'make all install'. Hmm... maybe my tree is screwed up in someother way... the generated Makefiles are full of "@foo@" magic. Shouldn't all of that have been subsituted away? find objtree -name "Makefile" | xargs -n 5 grep "@.*@" -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Does the name `Pavlov' ring a bell?
Re: Deadlock on class locks
Tim Wilkinson wrote:
There is already a classEntry lock associated with each class - perhaps
that could be used instead of adding a new lock?
Never thought of that... I looked through the code and, guess
what... the centry lock is already being used for exactly the same
type of syncronization. So, I changed the macros and fixed the
existing sites to use lockClass(). Here's a new patch (i.e., don't
apply the old one...).
As an alternative to this patch (which is 90% cleanup), one can just
change the locking in resolveString() to do lockMutex(clazz-centry)
instead of lockMutex(clazz).
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
To understand recursion one must first understand recursion.
Index: kaffe/kaffevm/classMethod.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/classMethod.c,v
retrieving revision 1.73
diff -u -r1.73 classMethod.c
--- kaffe/kaffevm/classMethod.c 1999/11/29 23:49:47 1.73
+++ kaffe/kaffevm/classMethod.c 1999/12/15 18:55:28
@@ -70,6 +70,8 @@
static bool resolveConstants(Hjava_lang_Class*, errorInfo *einfo);
static bool resolveInterfaces(Hjava_lang_Class *class, errorInfo *einfo);
+
+
#if !defined(ALIGNMENT_OF_SIZE)
#defineALIGNMENT_OF_SIZE(S)(S)
#endif
@@ -109,7 +111,7 @@
* we've got to work out.
*/
- lockMutex(class-head);
+ lockClass(class);
DBG(RESERROR,
/* show calls to processClass when debugging resolution errors */
@@ -145,7 +147,7 @@
goto done;
} else {
while (class-state == CSTATE_DOING_PREPARE) {
- waitCond(class-head, 0);
+ waitOnClass(class);
goto retry;
}
}
@@ -171,7 +173,7 @@
* upcall to a classloader, we must release the
* classLock here.
*/
- unlockMutex(class-head);
+ unlockClass(class);
#if defined(HAVE_GCJ_SUPPORT)
if (CLASS_GCJ(class)) {
class-superclass
@@ -185,7 +187,7 @@
#if defined(HAVE_GCJ_SUPPORT)
}
#endif
- lockMutex(class-head);
+ lockClass(class);
if (class-superclass == 0) {
success = false;
goto done;
@@ -262,7 +264,7 @@
SET_CLASS_STATE(CSTATE_PREPARED);
}
- assert(class == ObjectClass || class-superclass != 0);
+ assert((class == ObjectClass) || (class-superclass != NULL));
DO_CLASS_STATE(CSTATE_LINKED) {
@@ -335,7 +337,7 @@
goto done;
} else {
while (class-state == CSTATE_DOING_SUPER) {
- waitCond(class-head, 0);
+ waitOnClass(class);
goto retry;
}
}
@@ -387,10 +389,10 @@
* might call out into the superclass's initializer
* here!
*/
- unlockMutex(class-head);
+ unlockClass(class);
success = processClass(class-superclass,
CSTATE_COMPLETE, einfo);
- lockMutex(class-head);
+ lockClass(class);
if (success == false) {
if (class-superclass-state == CSTATE_INIT_FAILED)
SET_CLASS_STATE(CSTATE_INIT_FAILED);
@@ -431,7 +433,7 @@
goto done;
} else {
while (class-state == CSTATE_DOING_INIT) {
- waitCond(class-head, 0);
+ waitOnClass(class);
goto retry;
}
}
@@ -441,7 +443,7 @@
class-processingThread = THREAD_NATIVE();
/* give classLock up for the duration of this call */
- unlockMutex(class-head);
+ unlockClass(class);
/* we use JNI to catch possible exceptions, except
* during initialization, when JNI doesn't work yet.
@@ -464,7 +466,7 @@
callMethodA(meth, METHOD_INDIRECTMETHOD(meth), 0, 0, 0, 1);
}
-
Re: install errors
Archie Cobbs wrote:
Try completely blowing away your build directory hierarchy and
starting over.. this is what I do,
Yeah, that's what I end up doing from time to time. But, I really
rather not have to do that each time I change a header file. (That is
the point of Makefiles, after all...).
Perhaps we need some regression tests for the configure/build
environment?
... because of basic configure/libtool/automake paranoia.
Glad to see I'm not the only one frightened by the obtuse complexity
of these tools (heh, I used to think configure was bad...).
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
${HOME} is where the .emacs is.
install errors
With a very fresh snapshot, I'm getting errors during kaffe's install.
(See attached). If I re-make 'install', the error doesn't crop up
until the next library... (so it doesn't seem to be fatal).
I think the problem might be the '(' and ')' passed to -export-symbols-regexp.
-Pat
make[5]: Entering directory
`/z/tullmann/java/obj/kaffe-1.1-kaffe-jit-debug/libraries/clib/native'
make[5]: Nothing to be done for `install-exec-am'.
/bin/sh /n/marker/x/tullmann/janos/kaffe/mkinstalldirs
/n/alta/z/tullmann/java/install/kaffe-1.1-kaffe-jit-debug/lib/kaffe
/bin/sh ../../../libtool --mode=install /usr/bin/install -c libnative.la
/n/alta/z/tullmann/java/install/kaffe-1.1-kaffe-jit-debug/lib/kaffe/libnative.la
libtool: install: warning: relinking `libnative.la'
cd /z/tullmann/java/obj/kaffe-1.1-kaffe-jit-debug/libraries/clib/native; /bin/sh
../../../libtool --mode=relink gcc -g -O2 -Wall -Wstrict-prototypes -o libnative.la
-rpath /n/alta/z/tullmann/java/install/kaffe-1.1-kaffe-jit-debug/lib/kaffe -module
-release 1.0.5 -export-symbols-regex ^([Jj]ava|kaffe)_ ObjectStreamClassImpl.lo
Application.lo ByteToCharDefault.lo CharToByteDefault.lo Class.lo ClassLoader.lo
Compiler.lo Double.lo Float.lo Math.lo MemoryAdvice.lo Object.lo RMIHashes.lo
Runtime.lo SecurityManager.lo String.lo System.lo SystemClassLoader.lo Thread.lo
Throwable.lo UNIXProcess.lo ZipFile.lo Array.lo Constructor.lo Field.lo Method.lo
DateFormat.lo TestNative.lo Arrays.lo -lm -L/usr/local/lib -R/usr/local/lib
eval: 1: Syntax error: "(" unexpected
make[5]: *** [install-nativeLTLIBRARIES] Error 2
Re: install errors
Alexandre Oliva wrote: How fresh is that? About 1 hour old But you may have to remove all .la files in your build tree before his change takes effect. If I do a 'make clean', then install works just fine. However, if I change anything and rerun 'make install' I get the error. Its most definetly the quotes being stripped off the regexp (sh -x told me so). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] That which does not kill you just didn't try hard enough.
Re: install errors
Archie Cobbs wrote: Snapshot or CVS update? They are different I think. I should've mentioned that. CVS snapshot. You're Makefile's should have e.g. the patch below. Yep, they do. If this doesn't fix it for you, then there's some other problem. I think there is. If the tree is 'clean', then I get an install command line that contains: ... -export-symbols-regex ^\([Jj]ava\|kaffe\)_ ... if its dirty then I get a command without the '\' in it: ... -export-symbols-regex ^([Jj]ava|kaffe)_ ... That's really bizarre. I build into a separate tree from the source. I can't think of anything else that might be relevant about my setup. Let me know if you want more info from my setup... -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Indifference may cause the downfall of mankind, but who really cares?
