Re: [kaffe] Help me !!! I porting the kaffe on mpis cpu, but I had error of execution
No one seems to have replied to this message a month ago. I missed it at the time. First of all, I'm really suprised to see that you're running on an MIPS R6000. That's an multi-chip ECL CPU from the 1980s that was mostly installed in CDC servers. Is that really correct? The R6000 was the original "MIPS II" CPU, and there could easily be code in Linux and Kaffe that lumps the R6000 in with other, not-quite-compatible processors. That having been said, if you search the Kaffe mailing list archives, you will see that I observed the same problem months ago. First of all, you need to know that Kaffe 1.0.7 will not build and run correctly on MIPS unless you apply a patch. Kaffe 1.1.0 will build as distributed but you must not build it with the JIT, which was unfortunately still the default MIPS build as of 1.1.0.When youconfigure, you need to specify ".configure --with-engine=intrp". Regards, Kevin K. - Original Message - From: To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; Kaffe Mailing List Sent: Tuesday, October 07, 2003 4:21 AM Subject: [kaffe] Help me !!! I porting the kaffe on mpis cpu, but I had error of execution Hi Dear~~ I working the porting of kaffe My platform is CPU: MIPS R6000 OS: Redhat linux 2.4.17 Graphics: QT JVM : Kaffe 1.1.1 or Kaffe 1.1.0 or Kaffe 1.0.7 I following the bash-2.04# pwd /data/kaffe-1.1.0 bash-2.04# ./configure bash-2.04# make bash-2.04# make install I builded executiion file (java,javac,kaffe) bash-2.04# pwd/usr/local/kaffe/binbash-2.04# lsHelloWorld.class appletviewer java javah jdb kjc rmicinstall-jar javac javakey kaffe kopi rmiregistryjar javadoc javap kaffeh native2ascii serialver but don't execute java bash-2.04# ./java HelloWorldInternal error: caught an unexpected exception.Please check your CLASSPATH and your installation.java/lang/OutOfMemoryError at java.util.HashMap.rehash(HashMap.java:236) at java.util.HashMap.put(HashMap.java:136) at java.util.Hashtable.put(Hashtable.java:109) at java.lang.System.initProperties(System.java:native) at java.lang.System.clinit(System.java:43) at java.lang.ClassLoader.init(ClassLoader.java:114) at java.security.SecureClassLoader.init(SecureClassLoader.java:20) at kaffe.lang.AppClassLoader.init(AppClassLoader.java:238)! nbsp; at kaffe.lang.AppClassLoader.clinit(AppClassLoader.java:37)Aborted (core dumped) What is a problem I want to your advice Have nice day !!!
[kaffe] CVS kaffe (dalibor): Small cleanup of gc code
PatchSet 4158
Date: 2003/11/11 14:34:43
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Small cleanup of gc code
Members:
ChangeLog:1.1750-1.1751
kaffe/kaffevm/mem/gc-mem.c:1.50-1.51
kaffe/kaffevm/mem/gc-mem.h:1.17-1.18
Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.1750 kaffe/ChangeLog:1.1751
--- kaffe/ChangeLog:1.1750 Thu Nov 6 22:53:42 2003
+++ kaffe/ChangeLog Tue Nov 11 14:34:43 2003
@@ -1,3 +1,19 @@
+2003-11-11 Dalibor Topic [EMAIL PROTECTED]
+
+ * kaffe/kaffevm/mem/gc-mem.c:
+ (gc_magic) new constant.
+ (gc_set_magic_marker, gc_check_magic_marker) New inline functions.
+ (gc_heap_alloc) Use gc_check_magic_marker.
+ (gc_block_end) new function.
+ (gc_get_prim_freelist) Check that index is = 0 before accessing
+ array.
+ (gc_primitive_alloc) Use gc_block_end. Use gc_set_magic_marker.
+ (gc_primitive_free) Use gc_block_end.
+ (gc_heap_grow) Use gc_set_magic_marker.
+
+ * kaffe/kaffevm/mem/gc-mem.h:
+ (GC_MAGIC, GCBLOCKEND) Removed.
+
2003-11-06 Ito Kazumitsu [EMAIL PROTECTED]
libraries/javalib/gnu/xml/aelfred2/SAXDriver.java,
@@ -15,7 +31,6 @@
(bind, connect) Same commentary.
2003-11-03 Dalibor Topic [EMAIL PROTECTED]
-
* kaffe/kaffeh/support.c:
(kaffeh_findClass) Changed type of buf to unsigned char* to
fix -pedantic warnings.
Index: kaffe/kaffe/kaffevm/mem/gc-mem.c
diff -u kaffe/kaffe/kaffevm/mem/gc-mem.c:1.50 kaffe/kaffe/kaffevm/mem/gc-mem.c:1.51
--- kaffe/kaffe/kaffevm/mem/gc-mem.c:1.50 Fri Oct 10 20:05:56 2003
+++ kaffe/kaffe/kaffevm/mem/gc-mem.cTue Nov 11 14:34:45 2003
@@ -112,6 +112,23 @@
extern struct Hjava_lang_Thread* garbageman;
#ifdef KAFFE_VMDEBUG
+/* Magic constant used to mark blocks under gc's management */
+static const uint32 gc_magic = 0xD0DECADE;
+
+/* Set the magic marker of a block */
+static inline void
+gc_set_magic_marker(gc_block *b)
+{
+ b-magic = gc_magic;
+}
+
+/* Check the magic marker of a block */
+static inline bool
+gc_check_magic_marker(gc_block *b)
+{
+ return b-magic == gc_magic;
+}
+
/*
* analyze the slack incurred by small objects
*/
@@ -332,7 +349,7 @@
mem = blk-free;
DBG(GCDIAG,
- assert(blk-magic == GC_MAGIC);
+ assert(gc_check_magic_marker(blk));
ASSERT_ONBLOCK(mem, blk);
if (mem-next) ASSERT_ONBLOCK(mem-next, blk));
@@ -393,7 +410,7 @@
DBG(GCDIAG,
gc_heap_check();
- assert(info-magic == GC_MAGIC);
+ assert(gc_check_magic_marker(info));
assert(GC_GET_COLOUR(info, idx) != GC_COLOUR_FREE));
GC_SET_COLOUR(info, idx, GC_COLOUR_FREE);
@@ -486,7 +503,7 @@
nr = (gc_pgsize-ROUNDUPALIGN(1))/(sz+2);
/* Setup the meta-data for the block */
- DBG(GCDIAG, info-magic = GC_MAGIC);
+ DBG(GCDIAG, gc_set_magic_marker(info));
info-size = sz;
info-nr = nr;
@@ -536,7 +553,7 @@
}
/* Setup the meta-data for the block */
- DBG(GCDIAG, info-magic = GC_MAGIC);
+ DBG(GCDIAG, gc_set_magic_marker(info));
info-size = sz;
info-nr = 1;
@@ -601,6 +618,17 @@
b-nr = 0;
}
+/* Get the end a gc block
+ *
+ * This is OK, gc_prim_(alloc|free) never assume GCBLOCKEND is really
+ * a valid block
+ */
+static inline gc_block*
+gc_block_end(gc_block *b)
+{
+ return b + ((b-size+gc_pgsize-1)gc_pgbits);
+}
+
/* return the prim list blk belongs to */
static inline gc_block **
gc_get_prim_freelist (gc_block *blk)
@@ -609,6 +637,7 @@
if (sz = GC_PRIM_LIST_COUNT)
{
+ assert (sz 0);
return gc_prim_freelist[sz-1];
}
@@ -708,13 +737,13 @@
best_fit-size = sz;
- nptr = GCBLOCKEND(best_fit);
+ nptr = gc_block_end(best_fit);
nptr-size = diff;
gc_block_rm (nptr);
DBG(GCPRIM, dprintf (gc_primitive_alloc: splitted remaining
0x%x bytes @ %p\n, (unsigned int)diff, nptr); )
- DBG(GCDIAG, nptr-magic = GC_MAGIC);
+ DBG(GCDIAG, gc_set_magic_marker(nptr));
/* maintain list of primitive blocks */
nptr-pnext = best_fit-pnext;
@@ -785,12 +814,12 @@
/*
* Test whether this block is mergable with its successor.
-* We need to do the GCBLOCKEND check, since the heap may not be a continuous
+* We need to do the gc_block_end check, since the heap may not be a continuous
* memory area and thus two consecutive blocks need not be mergable.
*/
if ((blk=mem-pnext)
!GCBLOCKINUSE(blk)
- GCBLOCKEND(mem)==blk) {
+ gc_block_end(mem)==blk) {
DBG(GCPRIM, dprintf
Re: [kaffe] List of wanted test hardware?
S. Meslin-Weber wrote: Hi everyone, After a chat in #kaffe on freenode, I wondered if we could have a list of wanted test hardware up on kaffe.org - from the smallest to largest device. I have access to i[56]86-linux, i686-cygwin, i686-win32, i686-mingw, sparc-linux, sparc-solaris2, mips-irix, powerpc-darwin(ocassionally, and through Michael Frantz), powerpc-linux (Jason Perlow, evt. Sven Luther), arm-linux(handhelds.org), parisc-hpux, ia64-hpux, alpha-openvms, ia64-openvms, alpha-linux, ia64-linux, parisc-linux, arm-linux, alpha-freebsd, i686-freebsd, i686-openbsd, i686-netbsd. And in theory a few more at home, based on me having time to actually install them (i686-beos, i686-qnx, i686-solaris, i686-darwin, i686-unixware, i686-atheos, sparc-netbsd, sparc-openbsd). cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] libnative error
Hi folks I'm trying to shrink my 1.8Mb libnative.a so I can fit it on a pda. I fooled with the Makefile and did a strip on all the .o files. Everything links up fine but when I try to run a little sample program I get: $ java FirstClass Internal error: caught an unexpected exception. Please check your CLASSPATH and your installation. java/lang/UnsatisfiedLinkError: Failed to locate native function: java/lang/Throwable.fillInStackTrace()Ljava/lang/Throwable; at java.lang.Throwable.init(Throwable.java:37) at java.lang.Error.init(Error.java:69) at java.lang.VirtualMachineError.init(VirtualMachineError.java:17) at java.lang.StackOverflowError.init(StackOverflowError.java:17) Is stripping .o's forbidden for some reason. BTW, I generated the stripped libnative for i386. The target platform is mipsel. Am I running into some kind of i386ism that won't bother me on mipsel? Mark _ Concerned that messages may bounce because your Hotmail account is over limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Cygwin signal handling (or lack thereof) and kaffe cvs
Hi Nicholas, On Fri, 07 Nov 2003 09:41:38 -0500 Nicholas Wourms [EMAIL PROTECTED] wrote: Hi, I just went to try the latest kaffe cvs, when I noticed a critical issue in the build process. What, may I ask, are those of us using Cygwin supposed to do now that there is a `#error' directive in our md.h? I assure you that sigcontext will *NOT* be implemented anytime soon (trying to emulate POSIX signals via Windows signals is extremely complicated). I'm also certain this will also affect other non-linux platforms which use newlib. This was done by Guilhem Lavaux as part of the process of switching over to the Classpath I/O libraries. I haven't visited the problem myself, so I hope he can comment on the technical details. In general, I'd like to see Kaffe have the ability to be portable to non Posix platforms. It can be done, and has been done, but a lot of the work hasn't been merged back in yet. Why can't kaffe fall back to the prior signal handling when sigcontext is absent instead of being so heavy handed as to drop an #error directive (like it used to)? Tons of other, possibly more complex, projects seem to cope quite will without advanced signal handling. So what makes it so necessary now? Yes, I understand that java needs access to lowlevel routines at times, but you don't see this approach being done in libjava/gcj. IMHO, these recent changes make kaffe terribly unportable, which is something I thought most developers strive to avoid. Sorry if this sounds negative, but previous efforts led me to believe that making kaffe portable was one of its goals. Cheers, Nicholas Falling back to the previous behaviour sounds like a good idea. I wonder how much it is to put that back in? Patches are welcome. The biggest problem with supporting platforms like Cygwin is that we currently don't have anybody actively maintaining it. Even when I tested it last, circa 1.0.7, it seemed pretty broken to me. I think I would have been screaming pretty loud if what Guilhem did actually broke the port, but since it wasn't really working too well in the first place, I feel it falls more into the category of bitrot than actual regression. Again, Windows is an important platform, I'd love to see it work, but we need more help. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Cygwin signal handling (or lack thereof) and kaffe cvs
Jim Pick wrote: Hi Nicholas, On Fri, 07 Nov 2003 09:41:38 -0500 Nicholas Wourms [EMAIL PROTECTED] wrote: Hi, I just went to try the latest kaffe cvs, when I noticed a critical issue in the build process. What, may I ask, are those of us using Cygwin supposed to do now that there is a `#error' directive in our md.h? I assure you that sigcontext will *NOT* be implemented anytime soon (trying to emulate POSIX signals via Windows signals is extremely complicated). I'm also certain this will also affect other non-linux platforms which use newlib. This was done by Guilhem Lavaux as part of the process of switching over to the Classpath I/O libraries. I haven't visited the problem myself, so I hope he can comment on the technical details. It's not completely because of classpath's IO: I'm just using the multithread core of kaffe and haven't touched to the logic of signal handling. The real problem comes from interrupt in jthread.c: to be able to handle JVMPI you need the current exception frame through signal parameters. I don't even know if it can be turned around... Actually I had a look at Cygwin internals a few months ago and apparently they have the pointer we need in some place but they've decided not to put it in a parameter so we're blocked... I'll try to find another solution when I have some time (no prediction about that sorry). Cheers, Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] build errors
I'm attempting to build kaffe and I'm getting the following errors. Do you know what is causing this? [ checked body of java/util/zip/GZIPInputStream.java in 51 ms ] [ checked body of java/util/zip/GZIPOutputStream.java in 14 ms ] java/util/zip/ZipOutputStream.java:260: error:Variable LOCHDR is not defined in current context java/util/zip/ZipOutputStream.java:261: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:262: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:264: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:265: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:266: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:269: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:270: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:271: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:273: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:274: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:275: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:278: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:279: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:281: error:Local variable lh may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:284: error:Variable LOCHDR is not defined in current context java/util/zip/ZipOutputStream.java:152: error:Variable CENHDR is not defined in current context java/util/zip/ZipOutputStream.java:171: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:173: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:174: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:175: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:176: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:177: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:178: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:179: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:180: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:181: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:182: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:184: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:186: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:187: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:188: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:189: error:Local variable ch may have not been initialized before use [JLS 14.4] GC: heap 21508K, total before 20185K, after 14685K (357475/263506 objs) 31.7% free, alloced 8409K (#129649), marked 10425K, swept 5499K (#93969) 840 objs (19K) awaiting finalization java/util/zip/ZipOutputStream.java:191: error:Local variable ch may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:192: error:Variable CENHDR is not defined in current context java/util/zip/ZipOutputStream.java:212: error:Variable ENDHDR is not defined in current context java/util/zip/ZipOutputStream.java:213: error:Local variable ce may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:214: error:Local variable ce may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:215: error:Local variable ce may have not been initialized before use [JLS 14.4] java/util/zip/ZipOutputStream.java:216: error:Local variable ce may have not been initialized before use [JLS 14.4]
