Re: [kaffe] Some obscure(?) problem...
On Wed, 24 Apr 2002, Dalibor Topic wrote: While you are at it, you might want to take a look at xprof patches from Janos VM at http://www.cs.utah.edu/flux/janos/downloads/kaffe_kaffe_xprof.diff.gz They might help. Thanks, I'd forgotten about that. The patch seems to contain a whole lot of useful changes, but... /* * Unfortunately, I can't get linux to export a symbol to the gmonparam * structure (it doesn't link for some reason)... So we can't get any early * recordings. The last sentence is the important part, basically, if you don't care about not getting any of the samples taken between the start of main() and the initialization of xprof, its no big deal. Actually, i would imagine the data is still available in the regular gmon file, it just won't be rolled into xgmon file. -Jukka Santala tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problem: gcMalloc: Assertion `fidx nrTypes size != 0' failed.
hi, Hi Dalibor, Am sending a test program that results in the same assertion problem. The test program takes a jar file location, reads contents from each file in the jar and prints the same to standard output. It uses ZipFile and ZipEntry classes present in java.util.zip.* pkg. Attachments : Test.java -- source code of java file. Test.jar -- dummy jar file for input to the program. This contains the same Test.java. I was able to verify the problem, kaffe is trying to decompress a zero length file. So, when it allocates a buffer to inflate the data in, it crashes. But, i also tried it in janosvm's newer jar file code, but it doesn't like the format of the file, the size of the central directory didn't match the number of entries. This may or may not be a problem for kaffe as well. What did you use to make the jar file? Anyways, java_util_zip_ZipFile_getZipData0 in libraries/clib/native/ZipFile.c should prolly check for a zero length file before calling getDataJarFile(). Thanks regards, Santosh tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
Has anything happened with this bug? I was running developers/FullTest.sh on kaffe cvs/FreeBSD 4.3/gcc v2.95.3 and a similar thing was happening (e.g. StackDump seems to fail because it doesn't detect JNI exception handlers). tim stack I found one of the problems with Kaffe when compiling with -O4. Either the linker or the compiler is reordering the functions defined in jni.c. Normally this wouldn't matter, but Kaffe tries to identify if a program counter is in a JNI entry point method by testing to see if the PC is between Kaffe_JNI_estart and Kaffe_JNI_eend. Those two values are hardcoded to the first and last functions of interest defined in jni.c. When compiled with gcc -O4 (even with debugging and -g enabled, thank god), some of those methods are moved around. Specifically, the method used to invoke each new thread's run method uses Kaffe_CallVoidMethod, and on my machine the compiler moved that outside of the functions used to delimit the start and end of JNI-land. I hacked jni.c to iterate over all the pointers in the JNI entrypoint table and adjust the Kaffe_JNI_estart and Kaffe_JNI_eend until all of those methods were included. This fixed the particular test case (UncaughtException) but its exceedingly bogus because who knows what code was eventually included in this coverage. Unless someone knows of a good way of forcing a compiler/linker to keep a bunch of functions next to each other in the text segment, we'll need another approach. The best I could think of is to expand the current vmException buffer that's kept in each such method (they're chained and reachable off the thread object, see BEGIN_EXCEPTION_HANDLING in jni.c). If that struct could be expanded to include the address (and length!) of each the function its associated with, we could check the pc against that when looking for JNI exception handlers. Still for this approach to work, we'd need a way to get the size of a function's text out of the compiler... Anyone got other ideas? (Other than detecting and disabling -O4 in ./configure, of course...) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Not many people realize just how well known I am -- Anonymous ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe 1.0.7 Release Candidate 1 available for download
Hi, I've made the 1.0.7-rc1 release available for download at: ftp://ftp.kaffe.org/pub/kaffe/testing/v1.0.x/kaffe-1.0.7-rc1.tar.gz http://www.kaffe.org/ftp/pub/kaffe/testing/v1.0.x/kaffe-1.0.7-rc1.tar.gz Please download it, compile it, and try it out. This is a test release of what will be 1.0.7. Well, i used the CVS version from this morning because of the debugexithook problem: uname -a FreeBSD irontown 4.3-RELEASE FreeBSD 4.3-RELEASE #3: Wed Jul 11 00:35:12 MDT 2001 gcc -v Using builtin specs. gcc version 2.95.3 [FreeBSD] 20010315 (release) Here's the output from developes/FullTest.sh: kaffe-jit3-debug: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-debug: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-optimized: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... Command FAILED: make -s -j 2 -C /z/stack/tmp6/krc1/kabuild/kaffe-jit3-optimized/ check tail -5 /z/stack/tmp6/krc1/kabuild/Trace-kaffe-jit3-optimized.txt == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 FAIL: StackDump.java FAIL: UncaughtException.java FAIL: finalexc.java FAIL: InvTarExcTest.java FAIL: CLTestConc.java FAIL: ExceptionTestClassLoader2.java FAIL: ExceptionInInitializerTest.java FAIL: ProcessClassTest.java FAIL: ProcessClassInst.java FAIL: ProcessClassStop.java FAIL: TestNative.java kaffe-intrp-optimized: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-stats: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-stats: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-default: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-default: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-debug-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-debug-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-optimized-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... Command FAILED: make -s -j 2 -C /z/stack/tmp6/krc1/kabuild/kaffe-jit3-optimized-static/ check tail -5 /z/stack/tmp6/krc1/kabuild/Trace-kaffe-jit3-optimized-static.txt == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 FAIL: StackDump.java FAIL: UncaughtException.java FAIL: finalexc.java FAIL: InvTarExcTest.java FAIL: CLTestConc.java FAIL: ExceptionTestClassLoader2.java FAIL: ExceptionInInitializerTest.java FAIL: ProcessClassTest.java FAIL: ProcessClassInst.java FAIL: ProcessClassStop.java FAIL: TestNative.java kaffe-intrp-optimized-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-stats-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-stats-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-default-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-default-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... So, the only failure have to do with the -O4 jni problem mentioned previously. Cheers, - Jim tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
One idea I had was to have each JNI function in the
BEGIN_EXCEPTION_HANDLING macro store its start and size in the
'vmException' buffer. The problem is there is no
__builtin_function_size() GCC macro or anything that can tell you
that.
However, I know that there are tools that can generate such info from
a .o file.
So, we'd have to compile jni.c to jni.o, run a script over jni.o to
extract the length of each function, create a .c file that defines
'size_function_name' for each JNI entrypoint, compile that and link
it in.
The hardest part will probably be getting the Makefiles to do that. :)
I'll play around with this and see if it can be made to work (the
stack unwinding code will have to be updated, too).
What about using local labels in END_EXCEPTION_HANDLING?
#define BEGIN_EXCEPTION_HANDLING(X) \
vmException ebuf; \
ebuf.prev = (vmException*)unhand(getCurrentThread())-exceptPtr;\
ebuf.meth = (Method*)1; \
ebuf.start = jni_exception_start; \
ebuf.end = jni_exception_end; \
if (JTHREAD_SETJMP(ebuf.jbuf) != 0) { \
unhand(getCurrentThread())-exceptPtr = \
(struct Hkaffe_util_Ptr*)ebuf.prev; \
return X; \
} \
unhand(getCurrentThread())-exceptPtr = (structHkaffe_util_Ptr*)ebuf \
__label__ jni_exception_start;
#define END_EXCEPTION_HANDLING()\
__label__ jni_exception_end;\
unhand(getCurrentThread())-exceptPtr = (struct Hkaffe_util_Ptr*)ebuf.prev
This is based on:
http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values
-Pat
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] SHA1PRNG fix
hi,
I attached a patch for SHA1PRNG.java, it still wasn't quite doing what it
was supposed to. Also, i think i forgot to mention that this was based on
Classpath's (broken) code, so the copyright should probably be gpl'ed.
thanks,
tim stack
Index: SHA1PRNG.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/kaffe/security/provider/SHA1PRNG.java,v
retrieving revision 1.3
diff -u -r1.3 SHA1PRNG.java
--- SHA1PRNG.java 12 May 2002 15:08:46 - 1.3
+++ SHA1PRNG.java 3 Jun 2002 20:36:08 -
-6,10 +6,6
*
* See the file license.terms for information on usage and redistribution
* of this file.
- *
- * NB THIS DOES NOT ACTUALLY IMPLEMENT SHA1PRNG - it uses random and
- *is a place holder.
- *
*/
package kaffe.security.provider;
-25,14 +21,15
public class SHA1PRNG
extends SecureRandomSpi
{
- private static final int SEED_SIZE = 20;
- private static final int DATA_SIZE = 40;
+ private static final int SEED_SIZE = 8;
+ private static final int DATA_SIZE = 16;
private MessageDigest md;
private byte seed[] = new byte[SEED_SIZE];
private int seedPos = 0;
private byte data[] = new byte[DATA_SIZE];
private int dataPos = 0;
+ private long counter = 0;
public SHA1PRNG()
{
-43,7 +40,7
this.md = MessageDigest.getInstance(SHA-1);
new Random().nextBytes(this.seed);
- digest = this.md.digest(this.data);
+ digest = this.md.digest(this.seed);
System.arraycopy(digest, 0, this.data, 0, SEED_SIZE);
}
catch(NoSuchAlgorithmException e)
-77,7 +74,8
protected void engineNextBytes(byte[] bytes)
{
- if( bytes.length (20 - this.dataPos) )
+ this.counter += 1;
+ if( bytes.length (SEED_SIZE - this.dataPos) )
{
System.arraycopy(this.data, this.dataPos,
bytes, 0,
-112,6 +110,22
this.data,
SEED_SIZE,
SEED_SIZE);
+ this.data[SEED_SIZE] =
+ (byte)(this.counter);
+ this.data[SEED_SIZE + 1] =
+ (byte)(this.counter 8);
+ this.data[SEED_SIZE + 2] =
+ (byte)(this.counter 16);
+ this.data[SEED_SIZE + 3] =
+ (byte)(this.counter 24);
+ this.data[SEED_SIZE + 4] =
+ (byte)(this.counter 32);
+ this.data[SEED_SIZE + 5] =
+ (byte)(this.counter 40);
+ this.data[SEED_SIZE + 6] =
+ (byte)(this.counter 48);
+ this.data[SEED_SIZE + 7] =
+ (byte)(this.counter 56);
digest = this.md.digest(this.data);
System.arraycopy(digest,
0,
Re: [kaffe] SHA1PRNG fix
bah, i forgot a couple of other security fixes:
Change name of SHA - SHA-1
Add aliases to the Kaffe provider
tim stack
Index: SHA.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/kaffe/security/provider/SHA.java,v
retrieving revision 1.2
diff -u -r1.2 SHA.java
--- SHA.java22 Nov 2001 06:21:25 - 1.2
+++ SHA.java3 Jun 2002 20:57:57 -
-17,7 +17,7
public final class SHA extends UpdateDigest {
- public static final String DIGEST_NAME = SHA;
+ public static final String DIGEST_NAME = SHA-1;
public static final int DIGEST_LENGTH = 20;
public SHA() {
Index: Kaffe.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/kaffe/security/provider/Kaffe.java,v
retrieving revision 1.3
diff -u -r1.3 Kaffe.java
--- Kaffe.java 4 Jan 2002 05:12:33 - 1.3
+++ Kaffe.java 3 Jun 2002 20:57:57 -
-39,8 +39,12
kaffe.security.provider.MD4);
put(MessageDigest.MD5,
kaffe.security.provider.MD5);
- put(MessageDigest.SHA,
+ put(MessageDigest.SHA-1,
kaffe.security.provider.SHA);
+ put(Alg.Alias.MessageDigest.SHA1,
+ SHA-1);
+ put(Alg.Alias.MessageDigest.SHA,
+ SHA-1);
put(SecureRandom.SHA1PRNG,
kaffe.security.provider.SHA1PRNG);
return null;
Re: [kaffe] Problem with JNI...
Hi!
I have a slight problem with newer CVS versions of kaffe and JNI (both
1.06 and 1.07-rc1). After I configure and install kaffe, I can't get it
to work with my JNI programs. It keeps complaining that it cannot find
the shared library I have created. I have set CLASSPATH as well as
LD_LIBRARY_PATH to point to '.' in order to find the libraries and
classes in the current dir, and also to the directories where kaffes
libraries/classes are installed
The CVS version I'm using now is from Apr 26 and that works just fine,
when updating to a newer (need to install on another machine), I just
can't get it to work...
So, what does it print out?
I'm running Redhat 6.2 on a i386 machine. Kaffe is configured using
./configure --prefix=install dir --with-threads=unix-pthreads --without-x
If any of you either know what is wrong or what I may be doing wrong, I
would be very grateful for a quick answer.
Can you just run something basic like:
class foo
{
public static void main(String args[])
throws Throwable
{
System.loadLibrary(myLibrary);
}
}
regards Martin
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
I wrote:
(*) InternHog seems to fail in the (non-optimized) interp-debug builds
now. Of course, I can't get it to fail when run under GDB... Bah!
I'll keep poking at that one.
This is very bizarre.
i can replicate it here.
Kaffe seg-faults in string.c:stringCompare, when its passed the
strings 1812 and /tmp. Interestingly, those have the same
hashcode. The backtrace is:
#0 0x081113de in stringCompare (v1=0x83df800, v2=0x834a878) at
...kaffe/kaffevm/string.c:428
#1 0x0813c761 in hashFindSlot (tab=0x832c1c0, ptr=0x83df800) at
...kaffe/kaffevm/hashtab.c:189
#2 0x0813c562 in hashRemove (tab=0x832c1c0, ptr=0x83df800) at
...kaffe/kaffevm/hashtab.c:133
#3 0x0811122d in stringUninternString (string=0x83df800) at
...kaffe/kaffevm/string.c:352
#4 0x08111655 in stringDestroy (collector=0x8215460, obj=0x83df800) at
...kaffe/kaffevm/string.c:539
#5 0x080fa325 in finishGC (gcif=0x8215460) at
...kaffe/kaffevm/mem/gc-incremental.c:707
#6 0x080f9b6d in gcMan (arg=0x8215460) at
...kaffe/kaffevm/mem/gc-incremental.c:527
#7 0x08113547 in startSpecialThread (arg=0x8335c20) at
...kaffe/kaffevm/thread.c:273
Here are the strings:
(gdb) p* s1
$1 = {base = {dtable = 0x82e9c60, lock = 0x0}, value = 0x83defb0, offset = 0, count
= 4, interned = 1 '\001',
hash = 1515144}
(gdb) p* s2
$2 = {base = {dtable = 0x82e9c60, lock = 0x0}, value = 0x8346f18, offset = 0, count
= 4, interned = 1 '\001',
hash = 1515144}
They're both intern'd strings. s1 is the string being destroyed by the GC.
The SEGV occurs on the first dereference of the zero'th byte of one of
the strings. (My x86 assembly isn't very keen, here's a chunk of the
disassembly.)
...
0x81113d6 stringCompare+230: jmp0x8111400 stringCompare+272
0x81113d8 stringCompare+232: mov0xfff0(%ebp),%eax
0x81113db stringCompare+235: mov0xffec(%ebp),%edx
0x81113de stringCompare+238: movzwl (%eax),%eax
0x81113e1 stringCompare+241: cmp(%edx),%ax
0x81113e4 stringCompare+244: je 0x81113f0 stringCompare+256
0x81113e6 stringCompare+246: mov$0x1,%eax
0x81113eb stringCompare+251: jmp0x8111404 stringCompare+276
...
eip is on the movzwl instruction. eax is 0x83defbc. ebp is valid.
I can't dereference the arrays here:
$5 = {base = {dtable = 0x81a1c38, lock = 0x0}, value = 0x8290fb0, offset =
0, count = 4, interned = 1 '\001',
hash = 1515144}
(gdb) p $4.value
$6 = (HArrayOfChar *) 0x8290fb0
(gdb) p $4.value[0]
Error accessing memory address 0x8290fb0: Bad address.
(gdb) p $4.value[1]
So, is it possible for the character array to be freed before the string?
Adding code to check if the two arguments to stringCompare were
intern'd, and then seeing if they're == or not fixes the problem
because it avoids the dereference of the string contents Adding
printfs to the code indicates that this is the *only* time that two
intern'd strings are passed to stringCompare. I can't see any reason
why intern'd strings would cause a seg-fault, though.
I guess I'm curious if anyone else can reproduce this problem, and if
anyone else has any ideas as to what might be going wrong. (Or can
justify the fix from the previous paragraph.)
Not sure if the fix is valid. If they can be freed before the string,
then you'd have to avoid dereferencing all interned strings here...
-Pat
tim
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
Not sure if the fix is valid. If they can be freed before the string, then you'd have to avoid dereferencing all interned strings here... fyi, I hacked hashtab.c to avoid the deep comparison when removing a value. Now, it will just check the pointers and fail instead of also trying the comparison function. This seems to work, although i haven't gone through the entire run yet... tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SHA1PRNG fix
hi, I attached a patch for SHA1PRNG.java, it still wasn't quite doing what it was supposed to. Also, i think i forgot to mention that this was based on Classpath's (broken) code, so the copyright should probably be gpl'ed. oops, i whiffed again... in libraries/javalib/kaffe/security/provider/SHA1PRNG.java: @@ -112,6 +110,22 @@ this.data, SEED_SIZE, This is supposed to be zero. So it should look like: System.arraycopy(this.seed, 0, this.data, 0, SEED_SIZE); atleast, thats how i think its supposed to work. thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Also, to unintern the string you don't have to access its content (or do you?) Isn't that what Tim suggested? Hmm... I can't see how that avoids the fundamental problem of a live object with a pointer to dead space. If I have a String sitting in the hashtable that is dead, but not yet removed, how is a random thread prevented from creating a new String() with the same hashcode (and maybe the same contents) and coming across this string-without-chararray object in the table? indeed, forgot about this I'd say this was totally and utterly broken, but it hasn't been the pervasive problem I would except, so I must be missing something... well, this only applies to intern(), although i don't know how pervasive its use is beyond string constants in classes, which are unlikely to be freed. It also depends on memory layouts, your changes probably moved stuff around enough to cause problems Perhaps the destroy() function on GC objects could be run while moving white objects to the mustfree list in gc-incremental.c:finishGC? That would remove the Strings from the hashtable while the world is stopped, thus preventing any mutators from seeing half-dead objects in the string table. The comment in finishGC implies that this is bad because gc_heap_free() or something can block. I don't know if this still applies so heres a couple alternatives: Grab the intern lock before RESUMEWORLD() and release it after all the white objects have been destroyed. Add another call back which can be used to disable objects that are live from the internal perspective. -Pat tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Perhaps the intern'd string table should be walked, but only the char[] objects referenced from it should be marked (not the Strings). You could mark objects meant to be destroy()ed like objects meant to be finalized... I don't think this would work because the char[] could be gone before the String object is moved to the finalizer list... The only thing keeping the char[] alive is the live String reference. Right, marking the string implies that it would recursively mark the array. With some shuffling of the lists you could probably automagically implement the dependencies here, anything added to the grey/black list at this point would be swept after these objects. Also, I suppose you could just gc_add_ref() the array on intern and gc_rm_ref() on unintern. I don't think the unintern would ever get called because the String would always have a reference. This would solve the problem, but fill the string table with unused intern'd strings. :) er, gc_add_ref() _the array_ (i.e. gc_add_ref(string-value);), not the string object, thats what you proposed! :) Can we just drop the string table lock and use the gc_lock instead? They seem to be mingling quite a bit. Would this also solve the nastiness with the stringAlloc()/stringFree() functions having to unlock the stringLock. I think there was some effort to split these two locks in the past... there must have been a good reason for that I don't know if the increased contention for the lock would make any difference (or the potential recursive acquires) bah, the log gives no clues... -Pat tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Destroyed strings...
Another possible less intrusive idea: Why not just hold the string intern lock while working off the must-free list. Take it before working off the list, release it afterwards. I think we run into the same problem as before though, we can't take the lock before RESUMEWORLD() because it could deadlock and we can't take it after because of the race condition. In fact, if someone had the lock and was looking up a string before the gc calls STOPWORLD() we'd lose again. U1 hashFindSlot(FooBar); - thread switch just before it finds it, otherwise the collector would see the reference on the thread stack. GC STOPWORLD(); GC add FooBar to must free GC RESUMEWORLD(); GC lockStaticMutex(stringLock); - GC blocks waiting for U1 to finish U1 finds bogus FooBar Now, the reason i brought up weak references was that they could behave similarly: weak ref (i probably way off on how this is supposed to work): STOPWORLD(); weak ref (WR) placed on post processing list WR.disable() nulls out the reference if it is white some other conditions (e.g. low mem) RESUMEWORLD(); WR.destroy() puts the object on the ReferenceQueue (need to do it outside the RESUMEWORLD(); because someone can have the queue locked). interned string: STOPWORLD(); interned string (IS) is white IS.disable() nulls out the char[], preventing any matches. As stated above, if the thread already found it, the collector would've traced it. RESUMEWORLD(); IS.destroy() removes the string from the table. this seems to work, and theres no locking problem, i think... - Godmar tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
I wrote:
Tim wrote:
What about using local labels in END_EXCEPTION_HANDLING?
Ah! That's probably exactly what is needed. I was hoping there was
some GCC way of handling this.
Seems to work, too!
I had a little problem with:
static inline void
vmExcept_setJNIFrame(VmExceptHandler* eh, const void* start, const void*
end)
{
assert(eh);
assert(start != 0);
assert(start end);
eh-meth = VMEXCEPTHANDLER_KAFFEJNI_HANDLER;
eh-frame.jni.start = start;
eh-frame.jni.end = end;
}
in exception.h. The assert(start end); needs to be changed to
assert(start = end); otherwise it will fail if there are no
instructions between the start_label and end_label. Which seems to happen
with Kaffe_ExceptionOccurred() and if NEED_JNIREFS isn't defined...
-Pat
tim
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors,0 failures)
Patrick Tullmann wrote:
I was reading the VM spec last night, and it says that the end of an
exception range is exclusive, vs. the start being inclusive. Since
that's exactly what's happening (the exception is being re-tossed at
the very end of the coverage), I changed:
if (pc start_pc || pc end_pc) {
continue;
}
to:
if (pc start_pc || pc = end_pc) {
continue;
}
in the loop over the available exception handlers in
findExceptionBlockInMethod. This fixed the problem. However, that
comparison hasn't been touched since December `98. I have a hard time
believing the interpreter has never encountered this situation
before... (Perhaps the end_pc's were fixed up elsewhere at some
point?)
Hmm compiling it with kcj 'Version 2.1B released 17. July 2002' or
jikes 'Version 1.13 3/1/2001' doesn't make any difference... Also,
Sun's JDK1.4 can complete either compiled version of the test just
fine.
odd, i'm pretty sure it worked with a jikes v1.14 compiled file
So, I think that's the fix. I'm still wary because I wonder why it
ever worked... :)
noone uses intrp :) Which raises the question, why does it work fine
for the jitter and not intrp?
So, lets try and reexamine the whole thing...
First, what does the pc in the parameter list correspond to? The
current pc or the next pc?
For intrp, this gets set by runVirtualMachine intrp/machine.c:
register uintp pc = npc;
assert(npc meth-c.bcode.codelen);
mjbuf-pc = pc;
npc = pc + insnLen[code[pc]];
and read by dispatchException in exception.c:
/* Look for handler */
res = findExceptionBlockInMethod(frame-pc,
eobj-base.dtable-class,
frame-meth, einfo);
So, it uses the pc of the currently executing instruction...
For the jitter, this gets set by buildStackTrace in stackTrace.c:
info[cnt].pc = STACKTRACEPC(trace);
and read by unwindStackFrame in exception.c:
meth = findExceptionInMethod(frame-pc, class, einfo);
So, it uses the return pc found in the stack trace, which corresponds to
the next instruction to execute. Oops... Maybe we should change the
intrp engine to set mjbuf-pc to npc and see if that fixes it.
Also, grepping for end_pc turns up this code in checkCaughtExceptions
in jit/machine.c
/* include only if exception handler range matches pc */
if (meth-exception_table-entry[i].start_pc pc ||
meth-exception_table-entry[i].end_pc = pc)
continue;
Now, that doesn't look right to me...
-Pat
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors,0 failures)
Timothy Stack wrote: For the jitter, this gets set by buildStackTrace in stackTrace.c: info[cnt].pc = STACKTRACEPC(trace); So, it uses the return pc found in the stack trace, which corresponds to the next instruction to execute. er, spoke too quickly. For a synchronous interrupt and subsequent exception, this will be the current instruction. But, for a regular throw, it will be the next pc. But, the i386 freebsd and linux exception frame initializers add a one to the current pc: /* Get the first exception frame from a signal handler */ #define EXCEPTIONFRAME(f, c)\ (f).retbp = (c)-sc_ebp;\ (f).retpc = (c)-sc_eip + 1 tim stack again, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors, 0 failures)
On Tuesday, September 17, 2002, at 10:52 PM, Patrick Tullmann wrote: [infinite exception dispatch loops] So, lets try and reexamine the whole thing... First, what does the pc in the parameter list correspond to? The current pc or the next pc? Anyway, I would expect the pc passed to findExceptionBlockInMethod to be the current pc (i.e, the point where the exception occured). I think code that passes in something else is probably broken, right? agreed Oops... Maybe we should change the intrp engine to set mjbuf-pc to npc and see if that fixes it. Wouldn't that break the code that jumps to an exception handler and re-sets the PC based on the exception handler? From the looks of it, this is two distinct uses of the same field. The intrp engine uses it to tell the exception code where it is in the method and what handler should apply, but, otherwise the value placed in there is ignored. Then, the exception code uses it to tell the engine what code to execute next, in this case, the appropriate handler. It might be nice to use a union here to distinguish the two. For the jitter, this gets set by buildStackTrace in stackTrace.c: info[cnt].pc = STACKTRACEPC(trace); So, it uses the return pc found in the stack trace, which corresponds to the next instruction to execute. er, spoke too quickly. For a synchronous interrupt and subsequent exception, this will be the current instruction. But, for a regular throw, it will be the next pc. Hmm... that's the next *native* instruction. That's not necessarily the next bytecode instruction. (I imagine it usually happens to be so, though.) Alas, i seemed to have missed something in i386/jit.h: /* Extract the PC FP from the given frame */ #define PCFRAME(f) ((f)-retpc-1) #define FPFRAME(f) ((f)-retbp) So, when it gets pc its returning a pointer to the previous instruction. An x86 'call' is just one byte right? So, i guess that was working correctly and the EXCEPTIONFRAME macro is wrong. But, the i386 freebsd and linux exception frame initializers add a one to the current pc: /* Get the first exception frame from a signal handler */ #define EXCEPTIONFRAME(f, c) \ (f).retbp = (c)-sc_ebp;\ (f).retpc = (c)-sc_eip + 1 Ugh. I wonder if that was added to get around this exception problem? (that line is from March `98) Anyway, adding 1 to an x86 EIP isn't always going to point to a real instruction is it? nope It seems that the regular throw JIT case is the only one where we might have trouble getting the current PC (since the STACKTRACEPC() macro pulls the return code off the stack which is probably the first native instruction of the next bytecode). Seems to me that the right thing to happen is to fix that up with some magic and a comment, and have all the other cases record the current pc directly. Indeed, lets list the changes: Your fix for the exception range check. All EXCEPTIONFRAME() macros should set retpc to the current pc and not add one to it. Maybe make the pc field in vmException a union to clarify its use. Add a test, this is a bit complicated since you need an exception to be thrown on the very edge of the exception range. Add some bloody comments Also, grepping for end_pc turns up this code in checkCaughtExceptions in jit/machine.c /* include only if exception handler range matches pc */ if (meth-exception_table-entry[i].start_pc pc || meth-exception_table-entry[i].end_pc = pc) continue; Now, that doesn't look right to me... Heh, that's funny. Should the old jit just be removed from the current version? Do any architectures use it? i think a couple of platforms still use it... -Pat tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] patch for mauve thread tests
hi,
The most recent mauve has some thread tests that kaffe fails, the
following patch should fix the following problems:
The started field wasn't being set for the main thread
The group field wasn't being cleared after the thread died.
The setPriority() method should throw an IllegalArgumentException
if the parameter is outside the range [MIN_PRIORITY, MAX_PRIORITY],
and not the ThreadGroup's max priority. If the parameter was
greater than the group's max priority it should be set the priority
to the group's maximum.
Unfortunately, kjc is causing the other failures. Specifically, the
code it generates for the first part of the daemon test:
Thread current = Thread.currentThread();
boolean status = current.isDaemon();
boolean illegal_exception = false;
try
{
current.setDaemon(!status);
}
catch (IllegalThreadStateException itse)
{
illegal_exception = true;
}
Looks like this:
.method public test(Lgnu/testlet/TestHarness;)V
.limit stack 3
.limit locals 9
.line 48
invokestatic java/lang/Thread/currentThread()Ljava/lang/Thread;
astore 4
.line 50
aload 4
invokevirtual java/lang/Thread/isDaemon()Z
istore 5
.line 51
iconst_0
istore 6
.line 54
.catch java/lang/IllegalThreadStateException from Label1 to Label2 using
Label3
Label1:
aload 4
iload 5
iconst_1
ixor
invokevirtual java/lang/Thread/setDaemon(Z)V
Label2:
goto Label4
.line 56
Label3:
astore 5
.line 58
iconst_1
istore 6
.line 60
Label4:
aload_1
aload 4
invokevirtual java/lang/Thread/isDaemon()Z
iload 5
if_icmpeq Label5
iconst_0
goto Label6
Label5:
Notice how slot five is used to store result of the first isDaemon(),
however, the exception handler will store the exception in slot five.
Oh, for a real verifier.
tim stack
Index: kaffe/kaffevm/thread.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/thread.c,v
retrieving revision 1.45
diff -u -r1.45 thread.c
--- kaffe/kaffevm/thread.c 3 Oct 2002 07:11:24 - 1.45
+++ kaffe/kaffevm/thread.c 17 Oct 2002 16:21:21 -
@@ -239,6 +239,7 @@
unhand(tid)-interrupting = 0;
unhand(tid)-target = 0;
unhand(tid)-group = standardGroup;
+
unhand(tid)-started = 1;
initThreadLock(tid);
Index: libraries/javalib/java/lang/Thread.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/lang/Thread.java,v
retrieving revision 1.38
diff -u -r1.38 Thread.java
--- libraries/javalib/java/lang/Thread.java 3 Jul 2002 22:33:14 - 1.38
+++ libraries/javalib/java/lang/Thread.java 17 Oct 2002 16:21:22 -
@@ -194,12 +194,16 @@
*/
/* Not private for now so GCJ won't optimize it away */
void finish() {
+
ThreadGroup tg;
+
synchronized(this) {
dying = true;
notifyAll(); // in case somebody is joining on us
+
tg = this.group;
+
this.group = null;
}
-
if (group != null) {
-
group.remove(this);
+
if (tg != null) {
+
tg.remove(this);
}
Application.removeResource(this);
}
@@ -332,7 +336,7 @@
}
public final synchronized void setDaemon(boolean on) {
-
if (started !dying) {
+
if (started) {
throw new IllegalThreadStateException(Active Thread);
}
daemon = on;
@@ -345,8 +349,11 @@
public final void setPriority(int newPriority) {
checkAccess();
-
if (newPriority MIN_PRIORITY || newPriority group.getMaxPriority()) {
-
throw new IllegalArgumentException();
+
if (newPriority MIN_PRIORITY || newPriority MAX_PRIORITY) {
+
throw new IllegalArgumentException(Priority: + newPriority);
+
}
+
if (newPriority this.group.getMaxPriority()) {
+
newPriority = this.group.getMaxPriority();
}
setPriority0(newPriority);
}
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problem with garbage collection and p-threads
On Tuesday, October 29, 2002, at 02:41 AM, Martin Edlund wrote: Hi! I work together with Josef on this project, and this is the output we get from gdb This does not make any sense to us, but hopefully some of you can get something from it. The garbage collector needs to find the tops of each of the thread stacks in the system. Currently, i believe it does this by sending a SIGUSR1 signal to each thread where it will record the stack top and notify the collector that it has stopped. So, when debugging, you probably want to set gdb to ignore the signal unless you're debugging that part of the process. //Martin tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] (no subject)
hi tim,
hi
I'm writing it for linux and arch is IBM PowerPC405 . I'm compiling the
present one but getting the error-
/***ERROR LOG */
In file included from
/opt/hardhat/devkit/ppc/405/bin/../target/usr/include/stdio.h:33,
from debug.h:31,
from support.c:12:
/opt/hardhat/devkit/ppc/405/bin/../lib/gcc-lib/powerpc-hardhat-linux/2.95.3/
include/stddef.h:170: warning: empty declaration
In file included from
/opt/hardhat/devkit/ppc/405/bin/../target/usr/include/stdlib.h:391,
from ../../config/config-std.h:15,
from support.c:14:
/opt/hardhat/devkit/ppc/405/bin/../target/usr/include/sys/types.h:106:
warning: empty declaration
support.c: In function `sysdepCallMethod':
support.c:1051: Internal compiler error:
support.c:1051: internal error--insn does not satisfy its constraints:
(insn 998 995 507 (set (reg/v:DF 40 f8)
(mem:DF (plus:SI (reg:SI 31 r31)
(const_int 8 [0x8])) 0)) 441 {*movdf_softfloat32} (nil)
(nil))
make[3]: *** [support.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
/***END ERROR LOG */
I agree with dalibor, you should try upgrading. Another thing you can try
though is just compiling the sysdepCallMethod separately (its getting
inlined up there, so remove static inline and just compile the file),
that will give us a better idea of where the problem is.
Thanks,
Regards,
Sanjeev
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Weird memory leal|garbage problem
I receive this message: java.lang.OutOfMemoryError at MemBug.main(MemBug.java:12) I've replicated this, don't know whats causing it yet. Bizarre... Jean-Sebastien Bettez tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] memory leak in jit3 ?
On Saturday, December 28, 2002, at 11:03 AM, Dalibor Topic wrote: Hi, I've taken a second look at the pure java zip from GNU Classpath. I compared memory consumption using -verbosemem on i386-linux with jit3. I saw a big difference between jit-temp-data for the pure java zip and native zip version. Here are the stats for the pure java version: The funny thing is that the jit-temp-data doesn't go away after a while, as the name temp-data implies. My question is : how can I figure out if this is a memory leak? Most of the temp allocations are actually kept around across runs of the jitter. The seq/label/constpool infrastructure just make lists of objects and resize them when more are needed. However, it does seem unlikely they would be keeping 3 megs of objects around. So, you might want to start there and make sure that the lists aren't being broken and objects lost. What test case are you using? There is actually a leak in the jitter, but as far as i know, it only happens on an error condition, which seems unlikely in this case. The offending line is a malloc around machine.c:676, it should either be changed to a realloc or the codeblock variable should be freed somewhere besides finishInsnSequence(). I've also looked at the JanosVM 0.8 sources for jit3 and found that they are using a resetConst call to reset the constant pool. There is no such thing in current kaffe sources. Could merging in the JanosVM jit3 changes have a positive result on jit-temp-data usage ? Possibly, i can run a test case on our current internal version and report the results... best regards, dalibor topic tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] memory leak in jit3 ?
On Sunday, December 29, 2002, at 08:03 AM, Dalibor Topic wrote: Hi Tim, hi You need to apply the GNU Classpath java.util.zip replacement patch, available at http://www.kaffe.org/~robilad/zip-replacement-patch.tgz and to copy the Klasses.jar.bootstrap file over the existing copy in libraries/javalib. After installing the patched version of kaffe, simply running its jar tool on rt.jar as in kaffe -verbosemem kaffe.tools.jar.Jar xvf rt.jar should show more than 3 MB of jit-temp-data. Yep... the problem? The jitter sucks :). The thing thats tickling the bug is the static initializers in UnicodeTbl/UnicodeIdx. They are so large that they need a ton of memory to be compiled. So they force the jitter's label/const/seq object pools to be grown to an enormous size. Since these are not bounded, they end up staying around for the rest of the run. As for possible solutions? The quick and dirty way would be to just bound the pool sizes to some reasonable limit. The best solution would be to fix the jitter since the peak usage is still ginormous. best regards, dalibor topic tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [crash] Jython 2.1 Installer vs. jthread_disable_stop
Hi, hi, now that we've got Jython to run, I've tried to install it using the Jaython 2.1 installer from http://www.jython.org/download.html . That lead to an interesting crash: the jthread_disable_stop assert that checks if the disable_counter is less than 10 leads to a core dump. Increasing the disable_counter limit to 50 lets most of the installer run, but it still dumps core at the end of the installation process at the same assert. Finally, increasing the limit to 1000 leads to a core dump because of a stack over flow exception. Do you have a back trace from when it hits the assert? Preferably, from when the counter is at 10. Any idea how to debug this / what might be causing it / if it's fixed in JanosVM ? Maybe, but i doubt we can run jython at the moment. I'll be updating it to the current Kaffe CVS over the weekend so I can try it then. best regards, dalibor topic thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Is it a bug? System.loadLibrary() fails...
Hi Seongbeom, --- Kim, Seong Beom [EMAIL PROTECTED] wrote: zip -r rt.jar META-INF zip warning: name not matched: META-INF zip error: Nothing to do! (try: zip -r rt.jar . -i META-INF) gmake[1]: *** [rt.jar] error 12 gmake[1]: leave `/home/sbkim/work/i386/kaffe/libraries/javalib' directory ## ends You should do a clean checkout, and try again, given that you've got some problems with missing files/directories. I'm getting this too. The makefile doesn't seem to work if you configure in a different directory. This line: $(ZIP) -r rt.jar META-INF should probably be this: $(ZIP) -r rt.jar $(srcdir)/META-INF best regards, dalibor topic thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [crash] Jython 2.1 Installer vs. jthread_disable_stop
Hi, hi, now that we've got Jython to run, I've tried to install it using the Jaython 2.1 installer from http://www.jython.org/download.html . That lead to an interesting crash: the jthread_disable_stop assert that checks if the disable_counter is less than 10 leads to a core dump. Increasing the disable_counter limit to 50 lets most of the installer run, but it still dumps core at the end of the installation process at the same assert. There are quite a few nested internal locks, which causes the assert to fire... So, technically, increasing the number should be fine. A better fix would be to either get rid of support for stop(), handle unlocking internal locks when a thread is stopped, or reduce the amount of nesting. Finally, increasing the limit to 1000 leads to a core dump because of a stack over flow exception. A lame guess is that this is due to a cycle in the serialized objects and kaffe not being smart enough to notice. But, I don't know that much about the serialization code (pat touched it last if we go the hot potato route). Any idea how to debug this / what might be causing it / if it's fixed in JanosVM ? I dumped support for Thread.stop(), so we're immune that way. Theres also a bunch of other changes that might reduce the amount of nested locks... Btw, for me, jython takes _forever_ to open the installer window at startup. I don't see this behavior in the JanosVM, but it has some other bugs when painting the window (i haven't updated to the current cvs yet). best regards, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] pure java vs. native implementations
hi, So, on the discussion of replacing native library implementations with pure java versions from classpath, I don't see why they both can't be included. With a bit of configure magic everything should work fine... For example: if libgmp is available !force_pure_java: use native impl else use pure java impl Handling this at runtime would be nicer, but this should do for the majority of people I would think. thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] BCEL Verifier?
p.s. how is your verifier coming along? funny you should ask :) after a good number of months of little work (i was taking a graphics class that required a pretty enormous amount of programming), i've finally started picking it up again this week. pass 2 of verification is mostly done. the only major thing that still has to be done is to make sure that all field and method references in constant pool have valid names, classes, and type descriptors. which brings me to one question: does the class loader currently do any of that? Kaffe has some of this code (spread across verify.c, readClass.c, etc). The as-yet-unreleased JanosVM has just about everything else (i think) and a bunch of test cases (if you have jasmin/bcel installed). pass 3 (the big one with the data flow analysis) is mostly done. i'm still not 100% sure that i'm allocating memory the best way. at the moment, i call jthread_diable_stop, then use KALLOC to snag memory for the verifier, then do my verfication, then call KFREE followed by jthread_enable_stop at the end. that sound OK to you? yes, that should be fine. cheers, ~rob tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Jython 2.1 Installer slowness (was: [crash] Jython 2.1 ...)
Hi Tim,
hi,
Btw, for me, jython takes _forever_ to open the
installer window at
startup. I don't see this behavior in the JanosVM,
but it has some other
bugs when painting the window (i haven't updated to
the current cvs yet).
Well, for me too ;) It seems to hang on a thread
trying to load some images, but it never quite
succeeds and gives up loading them eventually. Weird.
With the update JanosVM is exhibiting the same behaviour.
Xdebugging shows the following:
#6 0x89212d4 in sleep__Q34java4lang6Threadx () at Thread.java:377
#7 0x87a8d7a in
loadImage__Q711cl0x863bca03net11sourceforge7liftoff9installer3awt11ImageCanvasPQ34java4lang6String
()
at ImageCanvas.java:71
#8 0x8affc1f in
__Q711cl0x863bca03net11sourceforge7liftoff9installer3awt11ImageCanvasPQ34java4lang6String
() at ImageCanvas.java:42
#9 0x8b01554 in
cl0x863bca0.net.sourceforge.liftoff.installer.awt.InstallerFrame.InstallerFrame
() at InstallerFrame.java:91
#10 0x87cea37 in
__Q611cl0x863bca03net11sourceforge7liftoff9installer8Install2Pt6JArray1ZPQ34java4lang6String
() at Install2.java:111
#11 0x8988ec3 in
main__Q611cl0x863bca03net11sourceforge7liftoff9installer8Install2Pt6JArray1ZPQ34java4lang6String
()
at Install2.java:130
With the installer code being:
int cnt = 0;
while( (checkImage(img,this) (ALLBITS) ) != ALLBITS ) {
try {
t.sleep(50);
} catch (Exception e) {
System.out.println(e);
}
if( cnt 300 )
return null;
cnt ++;
}
So, it looks like Component.checkImage() was broken between now and march
of last year (the last time i synced).
best regards,
dalibor topic
tim
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Bug report re: bug reporting
hi, I'd like to file a bug report stating that the current system for reporting bugs sucks. :) It seems to me that there are just too many people with problems that are going unanswered. Sure, we'll exchange some initial mail, but in the end people are just too busy with other things and Dalibor can't do it all by himself. Then the problem just gets lost in the archive and its too much of a pain to go back through trying to figure out what has and hasn't been fixed yet. So, basically, does anyone know of a bug reporting tool that can be setup on the web site without much trouble? thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] sound related configure bug
hi, I'm having problems building from the current CVS repository. The configure script is detecting libesd in /usr/local/lib, but /usr/local/include isn't in the include directory list when compiling. So, it goes boom. Looking at configure.in, it defaults to adding /usr/local/lib if --with-libraries isn't specified. So, i would suggest doing a similar thing for --with-includes. AC_ARG_WITH(includes, [ --with-includes=dirsSearch specified directories for header files], [ CPPFLAGS=$CPPFLAGS`echo $withval | sed -e 's/ / -I/g' -e 's/-I //g' -e 's/-I$//'` ], [ CPPFLAGS=$CPPFLAGS ]) Changes to: AC_ARG_WITH(includes, [ --with-includes=dirsSearch specified directories for header files], [ CPPFLAGS=$CPPFLAGS`echo $withval | sed -e 's/ / -I/g' -e 's/-I //g' -e 's/-I$//'` ], [ CPPFLAGS=$CPPFLAGS -I/usr/local/include ]) How's that sound? thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] --enable-pure-java-math not working yet
hi, The --enable-pure-java-math option doesn't seem to work quite right yet. When trying to link the main executable it can't find libmath since it was edited out of the build process. I think you just need to change configure.in to leave libmath out of the JAVA_LIBS variable if pure java math is turned on. JAVA_LIBS= \ \$(top_builddir)/libraries/clib/native/libnative.la \ \$(top_builddir)/libraries/clib/net/libnet.la \ \$(top_builddir)/libraries/clib/io/libio.la \ \$(top_builddir)/libraries/clib/zip/libzip.la \ \$(top_builddir)/libraries/clib/math/libmath.la \ \$(top_builddir)/libraries/clib/management/libmanagement.la \ \$(top_builddir)/libraries/clib/security/libsecurity.la \ \$(top_builddir)/libraries/extensions/microsoft/clib/libmicrosoft.la \ $AWT_LIB \ $JAVA_LIBS \ changes to: JAVA_LIBS= \ \$(top_builddir)/libraries/clib/native/libnative.la \ \$(top_builddir)/libraries/clib/net/libnet.la \ \$(top_builddir)/libraries/clib/io/libio.la \ \$(top_builddir)/libraries/clib/zip/libzip.la \ $MATH_LIB \ \$(top_builddir)/libraries/clib/management/libmanagement.la \ \$(top_builddir)/libraries/clib/security/libsecurity.la \ \$(top_builddir)/libraries/extensions/microsoft/clib/libmicrosoft.la \ $AWT_LIB \ $JAVA_LIBS \ (I'd submit a patch but i hate messing with autoconf/automake stuff...) thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Upgrading autotools requirements to a more recent version
Hi, hi, I'd like to do another round of asking who's using what version of auto* tools, and if upgrading kaffe to use the latest versions would be desirable or cause problems. See this thread for the last discussion of the issues involved: http://www.kaffe.org/pipermail/kaffe/2002-December/028418.html When i sync'd janosvm with the current kaffe I updated to the latest auto* tools, it wasn't too hard to do. My main complaint so far is that configure doesn't get run automatically after you run autogen.sh and the Makefiles don't regenerate themselves. Other than that it was a pretty easy transition. best regards, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] --enable-pure-java-math not working yet
Yeah, I've just seen it yesterday, too, and had a patch handy ;) thanks, I've checked in a fix, that does pretty much what you proposed. Now it doesn't work the other way ;)... This line in configure.in: MATH_LIB=$(top_builddir)/libraries/clib/math/libmath.la needs to look like this: MATH_LIB=\$(top_builddir)/libraries/clib/math/libmath.la Otherwise top_builddir doesn't resolve so MATH_LIB has a value of /libraries/clib/math/libmath.la cheers, dalibor topic thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re:_[kaffe]_Upgrading_autotools_requirements_to_a_more_recent_version
Dalibor wrote: I don't like the idea to force people to have the latest newest auto* tools just to be able to compile kaffe (hacking the build system is a different matter). It kind of beats the cross compatibility idea of running ./configure; make; make check. It turns it into autoreconf; slap forehead; get, build install latest auto* tools for the platform; run make check on the latest auto* tools for the platform and take a long walk outside; autoreconf; ./configure; make; make check; make install. FYI, the latest auto* tools seem to be a bit smarter about this and will regenerate Makefile's and Makefile.in's when the Makefile.am changes. However, it only does this if you specify --enable-maintainer-mode (took awhile before i figured this out...) cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [patch] auto* tools and misc make file changes
oops, attached now...
tim
Index: Makefile.am
===
RCS file: /cvs/kaffe/kaffe/Makefile.am,v
retrieving revision 1.23
diff -u -r1.23 Makefile.am
--- Makefile.am 20 Nov 2002 12:27:25 - 1.23
+++ Makefile.am 3 Feb 2003 18:37:05 -
@@ -10,6 +10,8 @@
SUBDIRS = . config include libltdl libraries/clib libraries/extensions kaffe
libraries/javalib test
+DIST_SUBDIRS = . config include libltdl kaffe libraries test
+
EXTRA_DIST = \
ChangeLog.1 \
ChangeLog.2 \
Index: configure.in
===
RCS file: /cvs/kaffe/kaffe/configure.in,v
retrieving revision 1.178
diff -u -r1.178 configure.in
--- configure.in3 Feb 2003 11:39:33 - 1.178
+++ configure.in3 Feb 2003 18:37:05 -
@@ -1,4 +1,4 @@
-AC_INIT(kaffe)
+AC_INIT(kaffe, 1.1.x-cvs, [EMAIL PROTECTED])
AM_INIT_AUTOMAKE(kaffe, 1.1.x-cvs)
AC_PREFIX_DEFAULT(/usr/local/kaffe)
@@ -18,6 +18,7 @@
abssrcdir=`pwd`/$srcdir
;;
esac
+AC_SUBST(abssrcdir)
dnl Setup version number.
KVER=$VERSION
@@ -82,7 +83,7 @@
fi
fi
-AC_ARG_WITH(staticbin,[ --with-staticbinForce the the creation of a static
virtual machine binary])
+AC_ARG_WITH(staticbin,[ --with-staticbinForce the creation of a static
+virtual machine binary])
if test x$with_staticbin = xyes ; then
vm_dynamic_binary=no
if test x${with_staticvm+set} != xset; then
@@ -432,9 +433,15 @@
dnl Use jikes instead of kjc?
dnl =
-AC_ARG_WITH(jikes,[ --with-jikes[=JIKES]Define to use jikes compiler
[default=no]],[JIKES=$withval],[JIKES=])
+AC_CHECK_PROG(JIKES, jikes, jikes)
+AC_ARG_WITH(jikes,[ --with-jikes[=JIKES] Define to use jikes
+compiler],[JIKES=$withval],[JIKES=$JIKES])
AC_MSG_CHECKING([whether to use jikes])
-if test x$with_jikes = x ; then
+if test x$JIKES != x ; then
+ use_jikes=yes ($JIKES)
+elif test x$with_jikes = x ; then
+ use_jikes=no
+ JIKES=
+elif test x$with_jikes = xno ; then
use_jikes=no
JIKES=
elif test x$with_jikes = xyes ; then
@@ -793,7 +800,11 @@
dnl We need both getrusage and the header containing its decls.
have_rusage=no
-AC_CHECK_HEADERS(sys/resource.h, AC_CHECK_FUNCS(getrusage, have_rusage=yes))
+have_resource_h=no
+AC_CHECK_HEADERS(sys/resource.h, have_resource_h=yes)
+if test x$have_resource_h = xyes; then
+ AC_CHECK_FUNCS(getrusage, have_rusage=yes)
+fi
dnl =
dnl Do we build a vm that collects statistics?
@@ -1213,6 +1224,10 @@
dnl Check for esd
+have_esd_h=no
+AC_CHECK_HEADER([esd.h],
+ [have_esd_h=yes],
+ [AC_MSG_RESULT([Warning: Could not find Enlightened Sound Daemon
+header file])])
AC_CHECK_LIB(
esd,
esd_open_sound,
@@ -1246,7 +1261,7 @@
no)
;;
*)
- if test $have_esd = yes; then
+ if test $have_esd = yes test $have_esd_h = yes; then
ESD_DIR=esd
fi
;;
Index: config/Makefile.am
===
RCS file: /cvs/kaffe/kaffe/config/Makefile.am,v
retrieving revision 1.21
diff -u -r1.21 Makefile.am
--- config/Makefile.am 2 Jun 2002 06:15:57 - 1.21
+++ config/Makefile.am 3 Feb 2003 18:37:05 -
@@ -12,7 +12,13 @@
ENGINE_GEN_HDRS =
endif
-GEN_HDRS = md.h xprofile-md.h $(ENGINE_GEN_HDRS)
+if ENABLE_XPROF
+XPROF_HDRS = xprofile-md.h
+else
+XPROF_HDRS =
+endif
+
+GEN_HDRS = md.h $(XPROF_HDRS) $(ENGINE_GEN_HDRS)
DISTCLEANFILES = $(GEN_HDRS)
Index: developers/autogen.sh
===
RCS file: /cvs/kaffe/kaffe/developers/autogen.sh,v
retrieving revision 1.4
diff -u -r1.4 autogen.sh
--- developers/autogen.sh 14 Nov 2002 22:19:34 - 1.4
+++ developers/autogen.sh 3 Feb 2003 18:37:05 -
@@ -9,7 +9,7 @@
##
## ( cd libraries/javalib ../../developers/update-class-list )
aclocal -I .
-autoheader -l config
+autoheader -I config
automake --add-missing --verbose
autoconf
Index: kaffe/kaffevm/Makefile.am
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/Makefile.am,v
retrieving revision 1.37
diff -u -r1.37 Makefile.am
--- kaffe/kaffevm/Makefile.am 2 Jun 2002 05:54:46 - 1.37
+++ kaffe/kaffevm/Makefile.am 3 Feb 2003 18:37:05 -
@@ -47,8 +47,10 @@
gc-mem.c \
md.c
+nodist_libkaffevm_la_SOURCES = \
+ $(libkaffevm_la_GEN_SRCS)
+
libkaffevm_la_SOURCES = \
- $(libkaffevm_la_GEN_SRCS) \
baseClasses.c \
classMethod.c \
classPool.c \
@@ -122,6 +124,8 @@
thread.h \
utf8const.h
+$(libkaffevm_la_SOURCES): $(libkaffevm_la_GEN_SRCS)
+
gc-mem.c: stamp-h01
@if test ! -f $@; then rm
Re: [kaffe] weird GC error with bad class format
Hi everyone.
hi,
i'm currently modifying kaffe's verifier (not posted yet because i'm
trying to get it more or less bug-for-bug compatible with Sun...they don't
really follow their own damn spec too closely, it turns out) and class
loader to take advantage of a GJ-like signature for running generic code
faster.
Could you post it anyways? Itd be nice to take a look at it.
the problem comes when the GJ Signature attribute is malformed. the
method readAttribute() in readClass.c returns false, and
kaffe-bin: mem/gc-incremental.c:1064: gcFree: Assertion `!!!Attempt to
explicitly free nonfixed object' failed.
is what i get.
So, I'm not seeing this, could you use gdb and give us a back trace? I am
seeing another error though, libraries/clib/native/SystemClassLoader.c has
a broken conditional:
if (!strcmp(info.classname, java.lang.NoClassDefFoundError)) {
...
}
else if ((info.type KERR_EXCEPTION)
!strcmp(info.classname, java.lang.NoClassDefFoundError))
{
}
It looks like patch just messed up, the second 'if' is the correct
conditional, but its block is empty. So, the block should be deleted and
the conditional moved up:
if ((info.type KERR_EXCEPTION)
!strcmp(info.classname, java.lang.NoClassDefFoundError))
{
...
}
this is bad because that means whenever a class file is
corrupted a little bit (or at least the attributes in a class file are
corrupted) and readAttribute returns false, this pretty bad thing happens.
to reproduce this, simply add the following case to readAttribute:
else if (!strcmp(name-data, Signature)) {
return false;
}
Are you using the current CVS?
cheers,
~rob
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] weird GC error with bad class format
Could you post a small patch?
attached
cheers,
dalibor topic
tim
Index: libraries/clib/native/SystemClassLoader.c
===
RCS file: /cvs/kaffe/kaffe/libraries/clib/native/SystemClassLoader.c,v
retrieving revision 1.6
diff -u -r1.6 SystemClassLoader.c
--- libraries/clib/native/SystemClassLoader.c 29 Jul 2002 14:52:13 - 1.6
+++ libraries/clib/native/SystemClassLoader.c 3 Feb 2003 21:43:04 -
@@ -78,7 +78,8 @@
* upgrade error to an exception if *this* class wasn't found.
* See discussion in Class.forName()
*/
- if (!strcmp(info.classname, java.lang.NoClassDefFoundError)) {
+ if ((info.type KERR_EXCEPTION)
+!strcmp(info.classname, java.lang.NoClassDefFoundError)) {
/*
* However, we don't upgrade if it is a second attempt
* to load a class whose loading has already failed.
@@ -105,11 +106,6 @@
%s, info.mess);
discardErrorInfo(info_tmp);
}
- }
- else if ((info.type KERR_EXCEPTION)
- !strcmp(info.classname, java.lang.NoClassDefFoundError))
-{
-
}
if (name != buffer) {
Re: [kaffe] weird GC error with bad class format
Hi Tim and Dalibor.
hi,
Are you using the current CVS?
i just downloaded a fresh copy of the current CVS, applied the patch Tim
posted and then made the change in readAttributes (readClass.c) that i
suggested earlier which is simply to add this case into the list of cases:
else if (!strcmp(name-data, Signature) {
return false;
}
Oh, forgot... Since you're returning false its expecting an error
message in 'einfo'. For example:
postExceptionMessage(einfo,
JAVA_LANG(ClassFormatError),
(class: %s) ...,
CLASS_CNAME(this));
otherwise, you get this error:
Exception thrown on null object ... aborting
Aborted
cheers,
~rob
tim
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe dalibor
Log message: 2003-02-03 Dalibor Topic [EMAIL PROTECTED] * libraries/javalib/kaffe/tools/jar/Jar.java: (updateFilesInJar) implemented. * libraries/javalib/Makefile.am: Use kaffe's jar tool instead of . This isn't working for me, it just generates an empty rt.jar. tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe dalibor
This isn't working for me, it just generates an empty rt.jar. Empty as in 0 bytes long, or empty as in it's a 350k long jar file with only 0 bytes long files ? 0 bytes That's on i386-freebsd, right? Yep, and built from a fresh checkout. cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe dalibor
Hi Tim, hi, very weird. I've just done a build on HP testdrive i386-freebsd machine, and it works for me. I've run ./configure; make in the source directory. Bah, you and you're source directory builds ;). Try configuring/building in a separate directory... cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe dalibor
Fixed checked in. I used $(srcdir) instead of $(abssrcdir). Yeah, that worked for me too. The reason it was failing silently is because Character.java couldn't load 'unicode.tbl' and 'unicode.idx'. Apparently, it will _only_ load them from a JAR file, so just specifying the 'lib' directory wasn't enough. And, since it was Character that was failing, it couldn't print out any error messages. cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] picky patch
Hi Rob, hi Tim hi, Sounds o.k. to me to rename the methods if they don't perform verification at all. ditto But before I check it in, I'd like to see class-analyze.[ch] from JanosVM merged into the kaffe CVS tree. There are two main diffs: CIF_* stuff, This change is a bit sketchy, i wouldn't add it yet. which is used in jit3 and powerpc jit and memory management changes, i.e. moving from KMALLOC to gc_malloc. Tim, should I merge it in as it is, and pull the jit3 changes in as well, plus the powerpc jitter, or leave the memory management stuff out, etc.? Maybe, maybe not. The next release will have a bunch of changes related to this, so you might want to wait a bit before making a decision on which bits to merge in. cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe dalibor
Btw, what is the status of make dist make distcheck ? Your patch should have improved some things there, but I was still having some problems with make dist when autotoolized using automake 1.4p5 autoconf 2.13 and make distcheck when autotoolized using automake 1.7.2 and autoconf 2.57. Hmm, haven't tried distcheck yet, i'll see about getting it working. If I remeber it correctly, make dist should generate a .tar.gz file that can be configured and built anywhere, even on i386-NetBSD. right? right That platform is currently broken because its make doesn't like the makefile after ./configure ... weird... The 'make dist' stuff was done because I'm trying to get a JanosVM release going. So, i only really try it on FreeBSD/Linux at the moment. cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] kaffe on oskit patches
hi, I've attached some patches that fix the kaffe on oskit build. The first file contains the necessary bits. The second file contains a small (untested!) patch for using zip to make the jar file, which is needed when cross-compiling since the kaffe executable won't work. The second patch is based on what is done in the JanosVM so it should work, or atleast come real close. 2003-02-12 Timothy S Stack [EMAIL PROTECTED] * config/i386/oskit/mkimage.sh: Fix the paths used to build the kernel image. (e.g. libexec/Kaffe - jre/bin/kaffe-bin) * kaffe/kaffevm/systems/oskit-pthreads/jthread.h: Add jthread_relaxstack() function. * configure.in: Add AM_CONDITIONAL(HAVE_ZIP, ...) so make files can use a regular zip if its available. * libraries/javalib/Makefile.am: Use detected zip executable to build the JAR file, needed to work in a cross-compile environment. thanks, tim Index: configure.in === RCS file: /cvs/kaffe/kaffe/configure.in,v retrieving revision 1.182 diff -u -r1.182 configure.in --- configure.in11 Feb 2003 21:58:42 - 1.182 +++ configure.in12 Feb 2003 18:39:54 - @@ -509,6 +509,8 @@ AC_PROG_MAKE_SET AC_CHECK_PROG(ZIP, zip, zip) +AM_CONDITIONAL(HAVE_ZIP, test x$ZIP != x) + dnl If symlink is overridden then don't bother with the test. if test x$LN_S = x ; then AC_PROG_LN_S Index: libraries/javalib/Makefile.am === RCS file: /cvs/kaffe/kaffe/libraries/javalib/Makefile.am,v retrieving revision 1.94 diff -u -r1.94 Makefile.am --- libraries/javalib/Makefile.am 11 Feb 2003 21:58:54 - 1.94 +++ libraries/javalib/Makefile.am 12 Feb 2003 18:40:19 - @@ -2272,6 +2272,14 @@ .PHONY: bootstrap bootstrap: $(srcdir)/Klasses.jar.bootstrap +if HAVE_ZIP +JAR_CMD1 = (cd $(srcdir) $(ZIP) -r rt.tmp.jar META-INF) ; mv $(srcdir)/rt.tmp.jar +rt.jar +JAR_CMD2 = (cd $(LIBDIR) $(ZIP) -DX -r ../rt.jar $(SRCDIRS)) +else +JAR_CMD1 = $(JAR) -cvf rt.jar -C $(LIBDIR) $(SRCDIRS) +JAR_CMD2 = $(JAR) -uvf rt.jar -C $(srcdir) META-INF/ +endif + .PHONY: jar-classes jar-classes rt.jar: $(LIBDIR)/stamp cp $(srcdir)/kaffe/lang/unicode.idx $(srcdir)/kaffe/lang/unicode.tbl $(LIBDIR)/kaffe/lang @@ -2279,8 +2287,8 @@ for i in $(serialized_converters) ; do cp $(srcdir)/$$i $(LIBDIR)/$$i ; done for i in $(gnu_regexp_message_bundles) ; do cp $(srcdir)/$$i $(LIBDIR)/$$i ; done rm -f rt.jar - $(JAR) -cvf rt.jar -C $(LIBDIR) $(SRCDIRS) - $(JAR) -uvf rt.jar -C $(srcdir) META-INF/ + $(JAR_CMD1) + $(JAR_CMD2) .PHONY: build-classes Klasses build-classes Klasses: rt.jar Index: config/i386/oskit/mkimage.sh === RCS file: /cvs/kaffe/kaffe/config/i386/oskit/mkimage.sh,v retrieving revision 1.4 diff -u -r1.4 mkimage.sh --- config/i386/oskit/mkimage.sh6 Mar 2000 18:20:32 - 1.4 +++ config/i386/oskit/mkimage.sh12 Feb 2003 18:40:33 - @@ -1,6 +1,6 @@ #!/bin/sh # -# Copyright (c) 1998, 1999 The University of Utah. All rights reserved. +# Copyright (c) 1998, 1999, 2003 The University of Utah. All rights reserved. # # See the file license.terms for information on usage and redistribution # of this file. @@ -134,7 +134,7 @@ CPF=$CLASSPATHFILE:/etc/kaffe_classpath # The Kaffe kernel -KAFFE=$KAFFEDIR/libexec/Kaffe +KAFFE=$KAFFEDIR/jre/bin/kaffe-bin if test ! -x $KAFFE; then echo ERROR: $KAFFE is not an executable. @@ -142,7 +142,7 @@ fi # The directory with the minimum necessary class files. -CLASSDIR=$KAFFEDIR/share/kaffe +CLASSDIR=$KAFFEDIR/jre/lib # The final list of directories DIRS=$CLASSDIR $DIRS @@ -192,7 +192,7 @@ done done - for FILE in $KAFFEDIR/lib/kaffe/*.la + for FILE in $KAFFEDIR/jre/lib/i386/*.la do echo $FILE:/lib/$(basename $FILE) done Index: kaffe/kaffevm/systems/oskit-pthreads/jthread.h === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/systems/oskit-pthreads/jthread.h,v retrieving revision 1.8 diff -u -r1.8 jthread.h --- kaffe/kaffevm/systems/oskit-pthreads/jthread.h 10 Dec 1999 07:49:04 - 1.8 +++ kaffe/kaffevm/systems/oskit-pthreads/jthread.h 12 Feb 2003 18:40:42 - @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 1999, 2000 The University of Utah. All rights reserved. + * Copyright (c) 1998, 1999, 2000, 2003 The University of Utah. All rights reserved. * * See the file license.terms for information on usage and redistribution * of this file. @@ -50,6 +50,8 @@ unsigned char flags;/* Thread flags */ } *jthread_t; +#define JTHREAD_FLAG_RELAXED 0x80 + /* * Map the cookie and jthread to
Re: [kaffe] Thread handling in Kaffe
On Monday, February 17, 2003, at 06:37 PM, calvin kaiwen wrote: Hi :) Glad you reply, here is a fraction of those code :) It is possible to increase the file descriptor of linux machine (yet to test out), but IF thread pool is reuse, 1024 file descriptors if more than enough :) Trying closing whatever files you're opening. The problem is known, in that Kaffe won't run the gc/finalizer if the process runs out of file descriptors. Therefore, any open FileInputStreams/FileOutputStreams won't be finalized immediately so the descriptors stay open. Calvin tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] IP address autodetection
On Sunday, February 23, 2003, at 11:48 AM, Matthew Toseland wrote: While trying to get freenet working on Kaffe, I discovered a side issue... we use the attached code to detect the local internet IP address. Basically, we open a datagram socket to the A-root nameserver and call getLocalAddress(). why not just use InetAddress.getLocalHost()? Or, useNetworkInterface.getNetworkInterfaces() and handle the NoClassDefFoundError with this method. This returns 0.0.0.0 on Kaffe CVS; Its probably wrong, but its a very gray area and making dependencies on it doesn't seem like a good idea. The javadoc for getLocalAddress() says it returns the local address to which the socket is bound, or an InetAddress representing any local address. Since the attached example didn't do a bind its technically correct to return the any address (0.0.0.0). Also, connecting a datagram socket discriminates on the remote address, not the network interface. So, again, its very dodgy behavior to be relying on. -- Matthew Toseland tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] IP address autodetection
On Sun, Feb 23, 2003 at 02:46:19PM -0700, Timothy Stack wrote: On Sunday, February 23, 2003, at 11:48 AM, Matthew Toseland wrote: While trying to get freenet working on Kaffe, I discovered a side issue... we use the attached code to detect the local internet IP address. Basically, we open a datagram socket to the A-root nameserver and call getLocalAddress(). why not just use InetAddress.getLocalHost()? Or,=20 Because it doesn't do what we want, at least in the Sun JVM? Care to elaborate? useNetworkInterface.getNetworkInterfaces() and handle the=20 NoClassDefFoundError with this method. Hm... this is supported by Kaffe? We'd have to have a fallback for pre-1.4 JVMs, yeah... I think its in CVS now. This returns 0.0.0.0 on Kaffe CVS; Its probably wrong, but its a very gray area and making dependencies on= it doesn't seem like a good idea. The javadoc for getLocalAddress()=20 says it returns the local address to which the socket is bound, or an=20 InetAddress representing any local address. Since the attached=20 example didn't do a bind its technically correct to return the any=20 address (0.0.0.0). Also, connecting a datagram socket discriminates on= the remote address, not the network interface. So, again, its very=20 Sorry, I don't understand connecting... interface. Suppose the local host is multihomed and it connects a datagram socket to another host. 231.42.21.152 (Host A: the remote host) | /---+\ |Internet| \--+--+--/ | | eth0 eth1 (Host B: the local host w/2 ethernet adapters) 34.21.12.2 34.21.22.3 Now, when host B connect()'s a datagram socket to host A, some[1] implementations will trigger a side effect that sets the socket's local IP address to that of the outgoing NIC. Basically, its a hacky way of querying the routing table. [1] Read Stevens' Unix Network Programming Vol. 1 Second Edition, section 8.14. Here's an excerpt from page 233: Unfortunately, this technique does not work on all implementations, notably SVR4-derived kernels. For example, this does not work on HP-UX, Solaris 2.5, and UnixWare, but it works on AIX, Digital Unix, Linux, and Solaris 2.6. Matthew Toseland tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] IP address autodetection
On Mon, Feb 24, 2003 at 09:56:42AM -0700, Timothy Stack wrote:
On Sun, Feb 23, 2003 at 02:46:19PM -0700, Timothy Stack wrote:
On Sunday, February 23, 2003, at 11:48 AM, Matthew Toseland wrote:
While trying to get freenet working on Kaffe, I discovered a side
issue... we use the attached code to detect the local internet IP
address. Basically, we open a datagram socket to the A-root nameserv=
er
and call getLocalAddress().
why not just use InetAddress.getLocalHost()? Or,=3D20
Because it doesn't do what we want, at least in the Sun JVM?
=20
Care to elaborate?
Hmmm, it returned 0.0.0.0
Kaffe? Or some broken JVM?
or the ethernet address.
Are you sure it wasn't an IPv6 address enclosed in an Inet6Address? The
spec isn't clear on which address (ipv4/ipv6 and/or which NIC) the VM is
supposed to return, so its a hard interface to use consistently. annoying
isn't it ;)
useNetworkInterface.getNetworkInterfaces() and handle the=3D20
NoClassDefFoundError with this method.
Does that mean I'd have to dynamically load the class? Or can I just
import it and enclose the section where I actually use it in a
try/catch?
yes, something like this should even work on kaffe:
InetAddress getLocalIPv4FromNetworkInterface()
throws SocketException,
NoClassDefFoundError
{
Enumeration enum;
enum = NetworkInterface.getNetworkInterfaces();
while( enum.hasMoreElements() )
{
NetworkInterface ni;
Enumeration addrs;
ni = (NetworkInterface)enum.nextElement();
addrs = ni.getInetAddresses();
while( addrs.hasMoreElements() )
{
InetAddress ia = (InetAddress)addrs.nextElement();
byte bits[];
bits = ia.getAddress();
if( bits.length == 4 !(bits[0] == 0x7F)
/* or whatever test u need */ )
{
return ia;
}
}
}
throw new SocketException(No valid InetAddresses found);
}
public InetAddress getLocalIPv4()
{
InetAddress retval;
try
{
retval = this.getLocalIPv4FromNetworkInterface();
}
catch(NoClassDefFoundError e)
{
retval = this.getLocalIPv4FromAltMethod();
}
catch(SocketException e)
{
retval = this.getLocalIPv4FromAltMethod();
}
return retval;
}
You'll also need to require developers to have a JVM/jar with
NetworkInterface/etc... or provide stub versions to compile against. I do
the latter with the Java NodeOS:
http://www.cs.utah.edu/flux/janos/jnodeos.html
Notice that we keep all references to NetworkInterface in its own separate
method. This works around a bug in kaffe's lazy class loading.
Basically, kaffe throws the NoClassDefFoundError at the method boundary
instead of the actual access point in the method.
Also, the current implementation of NetworkInterface in kaffe does the
lookup once, at initialization, and always returns the same result. I can
fix this if you need to be able to detect changes in the configuration
over time (this was on the to-do list anyways).
Matthew Toseland
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] JIT3 Questions
I've been looking at the problem with JIT3 on MIPS platforms,
and have come across something distinctly suspicious that I know
how to fix in the abstract. I could use some guidance from other
more experienced JIT hands as to how to best deal with it in practice.
In the generated function prologue in config/mips/jit3-mips.def,
we have...
=== Begin Source Fragment
define_insn(prologue, prologue_xxC) {
label* l;
Method* meth;
int limit;
int haveint;
int j;
int i;
int fi;
int a;
/* Max_args is the maximum number of arguments this method pushed
* onto the stack (allowing for alignment). We always allow for
* the 4 argument registers.
*/
max_args = NR_ARGUMENTS;
debug_name((prologue:\n));
/* Save and move sp, fp r31 */
insn_RRR(_ADDU, REG_i1, REG_fp, REG_i0);
insn_RRR(_ADDU, REG_fp, REG_sp, REG_i0);
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
insn_RRC(_ADDIU, REG_sp, REG_sp, 0); /* framesize */
ldst_RRC(_SW, REG_ra, REG_fp, -4); /* save $ra */
ldst_RRC(_SW, REG_i1, REG_fp, -8); /* save old $fp */
ldst_RRC(_SW, REG_gp, REG_fp, -12); /* save $gp */
debug((mov i1,fp\n));
debug((mov fp,sp\n));
debug((addiu sp,sp,-framesize\n));
debug((sw ra,-4(fp)\n));
debug((sw i1,-8(fp)\n));
debug((sw gp,-12(fp)\n));
#if defined(USE_JIT_CONSTANT_POOL)
/* Get pointer to constant pool */
insn_RRR(_ADDU, CONSTPOOL_BASE, REG_i25, REG_i0);
ldst_RRC(_SW, REG_gp, REG_fp, -16);
debug((movegp,i25\n));
debug((sw gp,-16(fp)\n));
#endif
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
%s,%d(fp)\n,regname(REG_s0+i),-SLOTSIZE*(4+i)));
}
== End Source Fragment ===
Now, as it happens, the offset generated to save register $16, i=0 in the for
loop above, ends up being -16. Which is to say, if USE_JIT_CONSTANT_POOL
is defined (which it is by default), the same storage location in the frame is used
for
both $16 and $25. Unfortunately, if I undefine USE_JIT_CONSTANT_POOL
in jit.h, where it is defined, the resulting JIT doesn't work. In the abstract, it
should
be a simple problem of upping the frame size by 8 bytes (8 not 4, to preserve
alignment),
and using a new offset for $25. However, in the code above, the frame size seems
to be generated automagically to replace a zero constant in the instruction
generation
macro with some method-dependent frame size that I speculate somehow already
allows for some number of saved registers in the frame. Where is this defined?
Are the offsets into the frame for the con
Is the relationship between the saved register context and other values on the
frame fixed, such that I cannot insert a new storage element between them?
I've been trying to code something really sneaky to save/restore the register
behind the back of the rest of the frame management code in a sort of
sub-frame, but the first cut at that doesn't work, and frankly, it's not what
I would consider to be wholesome coding. How can I adjust the total frame
size to add a new element?
Kevin K.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] JIT3 Questions
ops, sorry about the previous email
I've been looking at the problem with JIT3 on MIPS platforms,
and have come across something distinctly suspicious that I know
how to fix in the abstract. I could use some guidance from other
more experienced JIT hands as to how to best deal with it in practice.
In the generated function prologue in config/mips/jit3-mips.def,
we have...
=== Begin Source Fragment
define_insn(prologue, prologue_xxC) {
label* l;
Method* meth;
int limit;
int haveint;
int j;
int i;
int fi;
int a;
/* Max_args is the maximum number of arguments this method pushed
* onto the stack (allowing for alignment). We always allow for
* the 4 argument registers.
*/
max_args = NR_ARGUMENTS;
debug_name((prologue:\n));
/* Save and move sp, fp r31 */
insn_RRR(_ADDU, REG_i1, REG_fp, REG_i0);
insn_RRR(_ADDU, REG_fp, REG_sp, REG_i0);
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
insn_RRC(_ADDIU, REG_sp, REG_sp, 0); /* framesize */
ldst_RRC(_SW, REG_ra, REG_fp, -4); /* save $ra */
ldst_RRC(_SW, REG_i1, REG_fp, -8); /* save old $fp */
ldst_RRC(_SW, REG_gp, REG_fp, -12); /* save $gp */
debug((mov i1,fp\n));
debug((mov fp,sp\n));
debug((addiu sp,sp,-framesize\n));
debug((sw ra,-4(fp)\n));
debug((sw i1,-8(fp)\n));
debug((sw gp,-12(fp)\n));
#if defined(USE_JIT_CONSTANT_POOL)
/* Get pointer to constant pool */
insn_RRR(_ADDU, CONSTPOOL_BASE, REG_i25, REG_i0);
ldst_RRC(_SW, REG_gp, REG_fp, -16);
debug((movegp,i25\n));
debug((sw gp,-16(fp)\n));
#endif
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
%s,%d(fp)\n,regname(REG_s0+i),-SLOTSIZE*(4+i)));
}
== End Source Fragment ===
Now, as it happens, the offset generated to save register $16, i=0 in the for
loop above, ends up being -16. Which is to say, if USE_JIT_CONSTANT_POOL
is defined (which it is by default), the same storage location in the frame is used
for
both $16 and $25. Unfortunately, if I undefine USE_JIT_CONSTANT_POOL
in jit.h, where it is defined, the resulting JIT doesn't work. In the abstract, it
should
be a simple problem of upping the frame size by 8 bytes (8 not 4, to preserve
alignment),
and using a new offset for $25. However, in the code above, the frame size seems
to be generated automagically to replace a zero constant in the instruction
generation
macro with some method-dependent frame size that I speculate somehow already
allows for some number of saved registers in the frame. Where is this defined?
I think the 'label' stuff does what you want. In the mips case the code
that does the replacement is defined in jit.h:
#define LABEL_Lframe(P,V,L) \
{ \
int framesize = FRAMESIZE; \
assert((framesize 0xF000) == 0); \
*(P) = (*(P) 0x) | ((-framesize) 0x); \
}
...
#define EXTRA_LABELS(P,D,L) \
case Lframe:LABEL_Lframe(P,D,L);break; \
...
And the label is setup with this line from the prologue:
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
Then, when the jitter is doing post processing of the code it will
execute the LABEL_Lframe macro to replace the value at 'l-at'.
Is the relationship between the saved register context and other values on the
frame fixed, such that I cannot insert a new storage element between them?
Not really. You determine the layout of the stack frame so you can do
whatever you want. Its mostly a matter of tweaking the label macros
appropriately.
I've been trying to code something really sneaky to save/restore the register
behind the back of the rest of the frame management code in a sort of
sub-frame, but the first cut at that doesn't work, and frankly, it's not what
I would consider to be wholesome coding.
hmm... Can it not be worked into the existing frame management stuff?
This would benefit other architectures as well.
How can I adjust the total frame size to add a new element?
Just pump the 'framesize' value in the LABEL_Lframe() macro.
Kevin K.
tim
___
kaffe mailing list
[EMAIL PROTECTED]
Re: [kaffe] [Bug in CVS version] (-1)/2 == -1 sometimes
Hi all, hi With a current CVS version of Kaffe (compiled yesterday), the following program, compiled with Sun javac or kjc-- Thanks for the bug report, I've replicated it and am trying to fix it... Thanks, - Benja tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [Bug in CVS version] (-1)/2 == -1 sometimes
Hi all, hi, With a current CVS version of Kaffe (compiled yesterday), the following program, compiled with Sun javac or kjc-- ... gives me this output: [EMAIL PROTECTED]:/tmp$ /usr/local/kaffe/bin/java -cp . Foo 0 -1 CVS update and give it a try. The problem was that the jitter was using arithmetic shift to do divide, which doesn't quite work for signed integers. The fix is based on what gcc generates and seems to work. Thanks, - Benja thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Simple program shows strange results
hi,
In message Re: [kaffe] Simple program shows strange results
on 03/03/05, Ito Kazumitsu [EMAIL PROTECTED] writes:
I have made a simpler test program:
This strange problem occurs with float and double, but not
with int or byte.
$ cat Test.java.m4
public class Test {
public static void main(String[] args) {
T x = C1;
if (x C2) {
System.err.println(xC2: + x);
x = C2;
}
System.err.println(x);
}
}
CVS update and try this again. (Thanks for the test case!)
If you're interested, the causes were:
I modified move_float() in icode.c to look like
move_int/move_ref/etc since it was generating inefficient code on
the PowerPC.
Unfortunately, the x86 jitter depended on the way the old
move_float() worked, so it was not working properly when a slot
was aliased. For example, in the following bytecode:
ldc 10.0
fstore_1
fload_1
Kaffe optimizes away the store and subsequent load since it is
potentially redundant. Unfortunately, because of the bizarro way
the x86 FPU works, this does not work and the 10.0 value never
gets written to the proper place on the stack. Therefore, the
floating point number that gets printed is just whatever garbage
is on the stack at the time.
Solution:
Modify slotAlias() in machine.c to aggressively spill Rreadonce
registers (the x86 float register). This method works and seems
to generate the same code as before on x86 (as far as I know),
without screwing over CPUs with more sensible FPUs.
thanks,
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug [CVS version]: Calling non-implemented method in abstract class
Hi all, hi, The following code: --- snip --- gives me the following error: [EMAIL PROTECTED]:~/ff/fenfire$ /usr/local/kaffe/bin/kaffe -cp build Bug java.lang.NoSuchMethodError: Bug$Abstract.foo()V at Bug$Abstract.bug(source file unknown:line unknown, pc 0x81ff788) at Bug.main(source file unknown:line unknown, pc 0x8220661) My Kaffe version (compiled from CVS, on Debian / x86): Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Apparently, Kaffe doesn't like when an abstract class calls a method from an interface the abstract class implements, if the abstract class does not implement that method itself. Yeah, I ran into this a little while ago and fixed it in the JanosVM. Its actually because of a change in jikes, which is legal, but not handled correctly in Kaffe. I'll see about porting over the JanosVM fix in a bit. Thanks, - Benja thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Test results: FreeBSD 4.6
hi, I've attached a log of a FullTest.sh done on a 1Ghz PIII running FreeBSD 4.6. Basically, everything seemed to work, whee. Although it took forever to run... tim 267 irontown:release/kaffe uname -a FreeBSD irontown 4.6-STABLE FreeBSD 4.6-STABLE #0: Thu Aug 1 23:39:05 MDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UTAHUP i386 268 irontown:release/kaffe gmake --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-portbld-freebsd4.6 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to [EMAIL PROTECTED]. 269 irontown:release/kaffe gcc --version 2.95.4 270 irontown:release/kaffe jikes --version Jikes Compiler - Version 1.18 - 21 November 2002 (C) Copyright IBM Corp. 1997, 1998, 1999, 2000, 2001, 2002. - Licensed Materials - Program Property of IBM - All Rights Reserved. Originally written by Philippe Charles and David Shields of IBM Research, Jikes is now maintained and refined by the Jikes Project at: http://ibm.com/developerworks/opensource/jikes Please consult this URL for more information and for reporting problems. 312 irontown:kaffe/kaffe head ChangeLog 2003-06-05 Tim Stack [EMAIL PROTECTED] * libraries/javalib/bootstrap.classlist, libraries/javalib/Klasses.jar.bootstrap: Added java/util/AbstractList$2.class, java/security/AllPermission.class, java/security/PermissionCollection.class, and java/security/ProtectionDomain.class. 2003-06-04 Ito Kazumitsu [EMAIL PROTECTED] ./FullTest.sh output: Thu Jun 5 10:24:05 MDT 2003 kaffe-jit3-debug: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 10:41:48 MDT 2003 kaffe-intrp-debug: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 12:22:34 MDT 2003 kaffe-jit3-optimized: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 12:34:45 MDT 2003 kaffe-intrp-optimized: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 13:29:47 MDT 2003 kaffe-jit3-stats: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 13:46:38 MDT 2003 kaffe-intrp-stats: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 15:30:32 MDT 2003 kaffe-jit3-default: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 15:51:19 MDT 2003 kaffe-intrp-default: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 17:41:19 MDT 2003 kaffe-jit3-debug-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 17:54:18 MDT 2003 kaffe-intrp-debug-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 19:10:41 MDT 2003 kaffe-jit3-optimized-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 19:20:45 MDT 2003 kaffe-intrp-optimized-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 19:55:19 MDT 2003 kaffe-jit3-stats-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 20:08:09 MDT 2003 kaffe-intrp-stats-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 21:24:48 MDT 2003 kaffe-jit3-default-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all ... Installing ... Checking ... Thu Jun 5 21:37:33 MDT 2003 kaffe-intrp-default-static: Cleaning ... Configuring ... Building all ... Building Klasses ... Building bootstrap ... Building all
Re: [kaffe] Class loader checkins
hi, hi, I just checked in some code merged from the JanosVM, which include some fixes for the class loader and other bits. Update and give it a go. Hopefully, I didn't frell everything up... everything's working fine here, too ;) good However, I've got two small issues: Shouldn't the other methods of ClassLoader (like getPackage, getResource) also delegate to the PrimordialClassLoader if parent is null (seems to be what jdk does)? Could commit a patch if you agree. ops, yeah they probably should. I again tried running eclipse with Kaffe. Now it fails and complains about being unable to find java/lang/Object. Eclipse basically uses just an URLClassLoader (parent is null). Debug output shows that the loadClass method of that URLClassLoader is correctly called for java/lang/Object but returns null. Since this definitely worked before, I wonder if you have an idea of what could be going wrong here? I'll give it a look if you haven't fixed it yet. Greetings, Helmer tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] libraries/clib/net/InetAddressImpl.c cannot be compiled on old Linux
hi, On Thursday, May 29, 2003, at 10:00 PM, Ito Kazumitsu wrote: The current libraries/clib/net/InetAddressImpl.c and some others cannot be compiled on my poor old Linux (2.0.38) machine. What is wrong: (1) InetAddressImpl.c checks whether AF_INET6 and PF_INET6 are defined. Yes, they are defined in /usr/include/socketbits.h even on my old Linux host. But it does not support IPv6, so struct in6_addr is not defined. argh (2) InetAddressImpl.c uses getnameinfo which my old Linux host does not have. I don't understand, its supposed to be protected by an ifdef for getaddrinfo. Are you saying that it has getaddrinfo but not getnameinfo? Thats odd... I am afraid Linux 2.0 should be deleted from the list of supported systems. lets not be hasty tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] help with -Xxprof
Hai Please give me step by step instruction on how to run the xprof..I am having really tough time configuring with xprof with the FAQ file provided. Get the CVS version, I'm pretty sure it works just fine. I would really appreciate the help... Thanks Ram tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] libraries/clib/net/InetAddressImpl.c cannot be compiled on old Linux
On Friday, May 30, 2003, at 08:08 AM, Dalibor Topic wrote: 2. Patch replace/getifaddrs.c Old Linux does not have linux/netlink.h and linux/rtnetlink.h. So I do not expect kaffe to use replace/getifaddrs.c. I'll happily let Tim deal with the ipv6 stuff ;) Just some configure magic i think. 3. Install getaddrinfo. Get getaddrinfo-1.5.1.tar.gz from http://www.sra.co.jp/people/m-kasahr/getaddrinfo/ and compile getaddrinfo.c. This program provides getaddrinfo() and getnameinfo(). License is modified BSD without advertising clause, which is GPL compatible, so it can be merged in. It's up to Tim to decide if and how it should go in, as he wrote the IPv6 support. The existing code already falls back to the old style gethostbyname, its just that I didn't bother to check for both getaddrinfo/getnameinfo since it seemed like they would always come in pairs. Simple enough to just add a check for getnameinfo too... cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] jetty _almost_ works
hi, Sorry for the late checkins, I'm trying to help out some other folks, hopefully they won't cause any damage. Anyways, they get us pretty close to a working jetty (jetty.mortbay.org/jetty/). The server gets running, but for some reason it can't find any pages, bah. If anyone wants to help or has experience, please share :) tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jetty _almost_ works
Hi, hi, Sorry for the late checkins, I'm trying to help out some other folks, hopefully they won't cause any damage. Anyways, they get us pretty close to a working jetty (jetty.mortbay.org/jetty/). The server gets running, but for some reason it can't find any pages, bah. If anyone wants to help or has experience, please share :) I've got jetty up and running here :) The problem was that our FileURLConnection didn't return the correct Permission for the file it is connected to (patch attached). Should I commit this before the release or after it? Just so everyone knows, this patch fixed it! Greetings, Helmer thanks, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Release Dates (was Re: [kaffe] Qt AWT backend works under Qtopia(Qt Palmtop))
hi guys, (Sorry I haven't been active, work and all) On Tuesday, June 3, 2003, at 09:29 AM, Jim Pick wrote: Well, the original plan for 1.1.0 was to freeze on May 18th, and release on June 1st. Obviously, we didn't freeze on May 18th, and did not release on June 1st. I'll take the blame for that - I wasn't prepared... Nobody's fault, the dates were picked to allow for some buffering anyways. I'd just like to see it go before the 15th since I'll be on vacation then. My intention is to label the 1.1.x series of releases as development releases. We'll do a big 1.2.0 release sometime in the future, which we will label a production release. So we'll be following the convention as the Linux kernel, where odd-numbered minor number releases are development, and even-numbered minor number releases are production. Here's a proposal for 1.1.1 - I think we should do a two month cycle. Indeed, I've had it backwards all along. I wanted to stretch it out because I figured we wouldn't get a whole lot of development done in that amount of time. But, as seen by the last couple weeks, people come alive in response to a deadline ;) So, increasing the frequency is probably good for pushing things forward. (I'll stick with my conservative streak though and vote for three months ;). As for regression test results - what I'd like to do is to get some more automated reporting via the website. And maybe we could snapshot that for the development releases. This seems like a longer term project though, for future releases. That would be cool Cheers, - Jim tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] 1.1.0 Interpreter Performance
On Wednesday, June 11, 2003, at 06:01 AM, Helmer Krämer wrote: On Wed, 11 Jun 2003 13:02:16 +0200 Kevin D. Kissell [EMAIL PROTECTED] wrote: Our of curiousity, I configured the MIPS/Linux interpretive kaffe with --disable-debug, for speed, and ran the Embedded CaffeieneMark benchmark. Comparing the result with an equivalent 1.0.7-based build, we can see that a bunch of things have improved a little, some things have stayed the same, and that something has slowed down dramatically in string handling which more than cancells all the other improvements. [ test results skipped ] If you've got some time to waste, it'd be nice if you could compare the performance of 1.0.7's System.arraycopy() with the performance of 1.1.0's System.arraycopy() (nothing serious, just create a huge array and measure how long it takes to copy that array). Before going through the hassle of rebuilding/re-installing to try your experiment, I thought I'd look at the code. Jeez. No wonder. In 1.0.7, System.arraycopy() was a native method, defined in libraries/clib/native/System.c, which used the platform's memmov/memcpy functions. Now it's a Java implementation. Certainly easier to maintain that way, but it's unsurprising if it's more than 5 times slower. It's almost the same thing with jit3 on i386 here. With a pure java implementation of System.arraycopy() I get a String score of 1693, with a native implementation I get a String score of 2899. Given that System.arraycopy() is used all over the place, I'm currently tempted to revert the pure java implementation. Any thoughts? optimize the jitter! :) Greetings, Helmer tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] 1.1.0 on alpha-linux: make check crashes
On Wednesday, June 11, 2003, at 05:16 AM, Kevin D. Kissell wrote: Could you please check confirm that the 4 regression tests which succeed on alpha-linux are the same 4 that succeed with MIPS/Linux under jit3, i.e. HelloWorldApp.class.save CatchLimits.class.save TestFloatDouble, and ThreadStop? FYI, these tests almost always succeed (They have no output to check against so they pass by default). I think the only way they can fail is if the executable exits with an error code. tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
On Monday, June 30, 2003, at 04:54 AM, Gerlando Falauto wrote: Hi everyone, hi, (especially the JIT back-end coders) does anyone have any idea why _slot_slot_fconst is declared void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int) ^^ shouldn't there be a float instead? Its a problem, I think I went the wrong direction when fixing another problem, I'll look at it in a bit. Thanks! Gerlando tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] failed regression tests
Hi all, hi, * KaffeInternal.java: * /* Expected Output: java.lang.NoClassDefFoundError: kaffe/lang/ThreadStack */ what i got: java.lang.SecurityException: Prohibited package: kaffe/lang/ThreadStack I believe that what I got is the expected behavior, only that between the writing of the regression test and now the exception thrown for a class attempting to access something that it should not be accessing has changed. perhaps the expected output of the regression test should be updated? The NoClassDefFoundError is correct, I think. The SecurityException is because a non-primordial class loader has found the class file and is trying to define the class. However, the class file should only be in the boot class path and not the regular class path. So, you should make sure that rt.jar is not in CLASSPATH. Also, the current CVS version doesn't work for me at all: error compiling: java.lang.VerifyError: final method printArgs declared in class at/dms/kjc/CReferenceType is overriden in class at/dms/kjc/CClassNameType at at.dms.kjc.KjcTypeFactory.init(KjcTypeFactory.java:51) at at.dms.kjc.Main.createEnvironment(Main.java:235) at at.dms.kjc.Main.run(Main.java:116) at at.dms.kjc.Main.compile(Main.java:69) at at.dms.kjc.Main.main(Main.java:60) FAIL: HelloWorldApp.java Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] new machine-dependent source file
Hi Automake/autoconf experts, is there any way to add a new machine-dependent assembler (.s) or C (.c) file to the build process, and put it my config/cpu or config/cpu/os dir? I tried creating a cpu/os/Makefile.frag as its done in the engines and threadsystems directories, but that didn't quite work... It appears that the configure script looks for Make.frag and not Makefile.frag. Ah, gotta love the consistency... Thank you all! Gerlando tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] new machine-dependent source file
On Tue, 1 Jul 2003, Timothy Stack wrote: I tried creating a cpu/os/Makefile.frag as its done in the engines and threadsystems directories, but that didn't quite work... It appears that the configure script looks for Make.frag and not Makefile.frag. Ah, gotta love the consistency... Tried that, didn't work either. It said: CPU_SOURCES = sysdepCallMethod.s Did you add $(CPU_SOURCES) to the libkaffevm_la_SOURCES variable in kaffe/kaffevm/Makefile.am and regenerate it? No other platform seems to do that so I am the only one with this problem I think... PLEASE HELP! ;-) see config/mips/ultrix4/Make.frag Gerlando tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
Hi everyone, hi, (especially the JIT back-end coders) does anyone have any idea why _slot_slot_fconst is declared void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int) ^^ shouldn't there be a float instead? Can you update and try again. Gerlando thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Shutdown patch
Hi, hi, This patch adds the ShutdownHook (Java 1.3) feature to kaffe. Here is a=20 Changelog: Neat, can you make a test case for it please? Cheers, Guilhem. thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: running Java applications within kaffe (Re: [kaffe] shutdownHook changes broke the build)
hi Guilhem, I've just checked in a patch that fixed the remaining compilation problems for me. Cool, thanks. It now builds fine for me, but the shutdown hook test still fails. From a cursory examination it looks like some bad code is generated somewhere. The 'dummy' variable has a different value after the first call to addShutdownHook() :( Anyway, I'm not sure if running several java applications within a single kaffe instance is a good idea, as long as kaffe doesn't implement some of process separation features from JanosVM. It was a non-standard interface that noone (as far as I know) used anyways. So for example, what happens when an application calls runtime.exit()? It shouldn't shut down the whole machine, unless it's the only application running. It shouldn't run the finalizers of objects not belonging to it, and only run its own shutdown hooks. The exit code should be stored for later retrieval. I assume Tim could come up with further pitfalls. ;) Those are the high points :) cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: running Java applications within kaffe (Re: [kaffe] shutdownHook changes broke the build)
From a cursory examination it looks like some bad code is generated somewhere. The 'dummy' variable has a different value after the first call to addShutdownHook() :( FYI, I'm pretty sure its kjc's fault tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: running Java applications within kaffe (Re: [kaffe] shutdownHook changes broke the build)
From a cursory examination it looks like some bad code is generated somewhere. The 'dummy' variable has a different value after the first call to addShutdownHook() :( FYI, I'm pretty sure its kjc's fault Note to Rob: The verifier isn't picking up on the error like the jdk: Exception in thread main java.lang.VerifyError: (class: ShutdownHookTest, method: main signature: ([Ljava/lang/String;)V) Incompatible argument to function tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hi, hi, I don't see why instanceof or checkcast would need to be loaded aggressively during verification, but my hunch is that they're dealing with some of the same issues that I am. Namely, when checkcast is performed during execution simulation you'll need to be able to load a pointer to the class for type checking... I'll drop the JanosVM people a line to clarify this point. Well, I am the JanosVM person ;) Anyways, as I said in the reply, I just never got around to adapting them like the others. But yes, the lazy loading is what I'm trying to accomplish. verify3() is called when a class is about to be linked. At this point, according to the JVM spec you're not supposed to check whether a given class has a given field, or even whether a given class exists _unless_ you need that class for type checking (i.e. if you expect something of type A and have something of type B, then you have to load B to see if A is in its superclass type hierarchy). Can't you just use the signature like in code-analyse.c. Theres already a bunch of code in lookup.c for taking care of this stuff. Not really. The getField() and getClass() and getClassFromSignature() and stuff like that all cause the referenced class to be loaded and, in most cases, linked. The JanosVM versions don't, so you can try backporting those. I'm just not convinced you need to mess with class loading to do this. There is a lot of complexity and subtlety in loading and I would really like to avoid touching it without good cause. I'm not really talking about any serious modification to class loading. Every change to the loader is serious ;) All that would happen is that the memory allocation of the Hjava_lang_Class instance would happen earlier, allowing me to have a pointer to the class for type checking without loading the actual class. Again, right now the memory allocation is tied to the actual class loading. Everything else would remain as is. One example I can think of is that it might conflict with error handling. At the moment, the loader allows you to reload classes that fail early on, which mimics the behavior of jdk 1.3.1. This might not work anymore if the class pointer has to be stable and can't be replaced for a failed class. There might be other semantic changes that crop up as well... Basically, the only thing I know is that the lookup.c path is much less treacherous than trying to change the loader. Maybe I'm not explaining this well or maybe I'm overlooking some complications. Admittedly, I'm certainly not an expert about the class loading system of Kaffe. However, I'm pretty sure what I'm planning on doing isn't going to interfere with anything else, as classes will still be loaded through code-analyze just before they are needed at execution of a method. Should I post a patch that you can look at to better decide whether what I'm doing is a bad idea? Maybe... I could also write some tests to make sure the semantics of the loader aren't being changed. Thanks, Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hello, hi, The JanosVM versions don't, so you can try backporting those. Are you sure the janosVM versions don't force the referenced class to be linked? I just spent some time poking around the 1.0a source and it seems that they do... of course, I could simply be misreading something. Do you have example java code or is there any particular code in the VM that looks suspicious? Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] New server is up
On Wednesday, July 23, 2003, at 06:32 PM, Jim Pick wrote: Hi, hi, I think we're back... The motherboard on our server died suddenly late on Monday night, and I had to scramble to figure out what was wrong and basically build a new server. I ripped the old server out yesterday morning, got the parts yesterday evening, and I managed to get it all assembled and put back into the colo today (I had to take the day off work). Tell me if you see any problems... hopefully this doesn't become an annual ritual. :-) Works great as far as I can tell. Thanks for doing all that, we really appreciate it :) Cheers, - Jim tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] NIO in classpath
On Thursday, July 24, 2003, at 01:06 AM, Guilhem Lavaux wrote: Hi ! hi, I joined Kaffe developers recently and I am currently fixing things here and there. One of my current projects is to get a valid NIO implementation in Kaffe/Classpath. As I have already some work done (FileChannels on Kaffe, I may port these code to JNI) I was wondering if someone else is working on it... What aspect are you working on? Writing the java level code or porting the threading system(s)? Cheers, Guilhem. tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failures
Timothy Stack wrote: hi, hi, Thanks, I didn't notice we had different failures. ops, I didn't look close enough, the intrp ones are my fault... I need to fix it so jvmpi works right. should be fixed by attached patch. cheers, dalibor topic thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Quick Stack Trace Question
Hi all, hi, When my verifier throws a VerifyError kaffe exits fine, but I get a: No stacktrace available What generally causes a lack of stacktrace being available? I'm assuming you're trying to execute a broken class on the command line... In which case, the VM never gets a chance to execute anything since the main class is failing to verify, hence, no trace. I also don't get a stack trace using Sun's java, but it at least doesn't give me a No stacktrace available. I imagine its a recent change, it should probably be removed to match the sun behavior. Just making sure what's happening is OK :) it is Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Debugging Help
Hi all, hi, Attached is a patch for a nearly completed bytecode verifier. There are two things that are still not checked that are required by JVM Spec 4.8.2, but they will be pretty simple to add in later. Well, first, there are a couple references to 'free()' which should be 'KFREE()'. Second, try running the test suite with kjc instead of jikes since its tripping over an assert for me (I don't have time to fix/look at this at the moment). Kaffe with verification passes all the usual regression tests with it except for LostTrampolineFrame. The VerifyError is raised when LostTrampolineFrame$DamagedClass is verified, and is caught by the wrong handler. I don't really know what's going on with that test, and have tried following it in gdb, but am having troubles deducing the problem. This is benign. Before your stuff, the exception was thrown while jitting, which triggered the case I was trying to test (the trampoline was masking the frame that originally made the method call). But now the exception is thrown during loading, so the fix is to find another way to make the jitter throw an exception... Thanks, Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Jython
hi guys, CVS update and try again... I'm able to run it, but I get an occasional 'java.io.IOError: Bad file descriptor', haven't looked into it though. Also, it turns out the installer they use is broken and doesn't check for errors when loading images. So, if kaffe doesn't find a gif library during configure the installer will get stuck and take a long time to finally timeout. thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] static vm on mipsel
Hi folks I've compiled kaffe for mipsel and wound up with a dynamically linked kaffe-bin. One of the FAQs says to give configure --with-staticvm and it will link statically. I did, but got a dynamically linked kaffa-bin again. Is there any way to force it to build statically? Try --with-staticvm AND --with-statclib Mark tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] completed bytecode verifier!
Hi all, I just committed the bytecode verifier. It's a huge chunk of code and it's very likely that there are little bugs lurking around in it...I can't even count how many off-by-one errors I had during development. make check-TESTS make[1]: Entering directory `/z/stack/tmp0/kbuild/test/regression' PASS: HelloWorldApp.class.save error compiling: java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; No stacktrace available FAIL: HelloWorldApp.java error compiling: java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; No stacktrace available FAIL: TestIntLong.java error compiling: java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; No stacktrace available Bah, forgot to mention that this was from a fresh checkout and compile on freebsd 4.6. tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] completed bytecode verifier!
Hi Tim, hi, I think I managed to figure out what is going wrong here. Hopefully my explanations will not get too confusing. Thanks, I understood it just fine. First of all, you might consider applying the attached patch, since it will give you some better error messages in case some type could not be resolved during verification (do you know why getClassFromSignature throws away the einfo from classFromSig?). Its broken... It should return NULL immediately if classFromSig fails to load the class. And the check for consuming all characters in string should be done by the verifier. And, it might leak memory since it doesn't call discardErrorInfo... Anyways... If you try running $JAVA at.dms.kjc.CSourceClass afterwards, you will see that kaffe thinks that it has detected a ClassCircularityError. Now comes the confusing part, since I'll try to explain what I think is going on here ;) First of all, CSourceClass is derived from CClass, which is derived from CMember (all in package at.dms.kjc). So when kaffe has to load CSourceClass, that will trigger loading CClass and loading CClass in turn will trigger loading CMember. This will cause kaffe to process CMember to state CSTATE_LINKED, while CSourceClass and CClass are both in the CSTATE_LOADED_SUPER state (and their classMappingState is NMS_LOADING). Processing CMember to CSTATE_LINKED however, includes verifcation of the class CMember (both, verify2 and verify3). But in order to do this, the verifier has to resolve the types CSourceClass and CClass (they are needed for type checking during verification of the getAccessorOwner method). Since the verifier uses loadClass() to resolve the type, the ClassCircularityError is thrown (because classMappingSearch detects that the state is NMS_LOADING and that the current thread is responsible for it). Next problem is that the verifier needs a class that is at least in state = CSTATE_LOADED_SUPER (otherwise it could not check for inheritance). An idea how to fix this? My guess would be to defer verification of the superclass until after the subclass is in state CSTATE_LOADED_SUPER (and NMS_LOADED). This could probably be done by creating a special getClass() that returns a class that is only CSTATE_PREPARED, I don't think this will work with user loaders since getClass() calls loadClass(), which can call a user loader, which can do whatever it wants. but not CSTATE_LINKED. The subclass would load the superclass using this special getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING) and process the superclass to CSTATE_LINKED afterwards. That way, the verifier would be able to properly resolve the subclass while verifying the superclass, but detection of ClassCircularityErrors should still work? I think the circularity checking is broken, its just checking to see if there is a loop in calls to loadClass and not checking that its still trying to load the super class. For example, in this case CMember would have finished loading its super (java.lang.Object) so there is no circularity. I'm thinking the fix would involve a new class state and classEntry state that break up the loading of the super class. I'll try to look at it more over the weekend... Greetings, Helmer tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jvmpi
hi Tim, hi, I've checked in some JVMPI stuff. Its not completely done yet, but its a pretty good start. I'll try and get it finish RSN. Hopefully, i didn't break anything... thanks! I've tried to build kaffe with jvmpi enabled, but it breaks during linking because a function is missing. I've modified the Makefile.am to link in libkaffevm, and I thought about exporting the missing function, but you seem to use it in jvmpi_kaffe.c with a different signature, so I'm not sure how to get JVMPI to build ;) Whats the function? Oh, and do you know of any JVMPI applications that would work with your implementation and kaffe? I was mainly just gonna try and get sun's hprof to work. I actually have some more of it written in my local tree, but I still need to implement the dump stuff. I'll try to get to that over the weekend too. cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] completed bytecode verifier!
Hi all, I just committed the bytecode verifier. It's a huge chunk of code and it's very likely that there are little bugs lurking around in it...I can't even count how many off-by-one errors I had during development. make check-TESTS make[1]: Entering directory `/z/stack/tmp0/kbuild/test/regression' PASS: HelloWorldApp.class.save error compiling: java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; No stacktrace available FAIL: HelloWorldApp.java error compiling: java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; No stacktrace available FAIL: TestIntLong.java error compiling: java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; No stacktrace available - The new instruction cannot be used to create an instance of an abstract class. This should be checked, but it cannot be checked by the verifier because the verifier cannot load classes unless they are necessary for type checking. Thus if the type of class created by the new instruction is not loaded, there's no way to check if it's abstract. This should be checked in code-analyse. This isn't done for the sake of binary compatibility. For example, if a base class adds an abstract method, you don't want to screw up any subclasses in different packages if the method isn't going to be called. Instead, you wait until it actually is called and throw an AbstractMethodError. Cheers, Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] completed bytecode verifier!
On Friday, August 8, 2003, at 10:22 AM, Timothy Stack wrote:but not CSTATE_LINKED. The subclass would load the superclass using this special getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING) and process the superclass to CSTATE_LINKED afterwards. That way, the verifier would be able to properly resolve the subclass while verifying the superclass, but detection of ClassCircularityErrors should still work? I think the circularity checking is broken, its just checking to see if there is a loop in calls to loadClass and not checking that its still trying to load the super class. For example, in this case CMember would have finished loading its super (java.lang.Object) so there is no circularity. I'm thinking the fix would involve a new class state and classEntry state that break up the loading of the super class. I'll try to look at it more over the weekend... Did I say last weekend, I meant this weekend... Anyways, the only way I could figure out how to fix this was to start another thread to do the load. Its not ideal, but I'm having trouble finding any other way to do it that works with user loaders. Helmer tim tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (hkraemer): fixed mem leak in garbage collector
On Friday, August 22, 2003, at 05:43 AM, Kaffe CVS wrote: PatchSet 3971 Date: 2003/08/22 11:42:13 Author: hkraemer Branch: HEAD Tag: (none) Log: fixed mem leak in garbage collector Can you elaborate on what was going on here? thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Classpath's IO/net subsystem merging + fixes.
On Sat, 30 Aug 2003 07:20:57 -0700 Kaffe CVS [EMAIL PROTECTED] wrote: PatchSet 3996 Date: 2003/08/30 14:18:17 Author: guilhem Branch: HEAD Tag: (none) Log: Classpath's IO/net subsystem merging + fixes. Nice work! That's going to help me out a lot. I compiled it 4 times, and I found some possible regressions (x86/Linux/defaults), all intermittent: * GCTest.java - I had 2 failures in 4 runs of make check * NetworkInterfaceTest.java - I had 1 failure in 4 runs of make check NetworkInterfaceTest, InetAddressTest, and InetSocketAddressTest fail for me... - Jim tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jvmpi
hi, I've checked in some JVMPI stuff. Its not completely done yet, but its a pretty good start. I'll try and get it finish RSN. Hopefully, i didn't break anything... Real soon now indeed... The last checkin gets things a bit farther, atleast for the jit3/unix-jthreads configuration. I can run the tracer for the Extensible Java Profiler and get reasonable output for method traces, but the class loader trace does not seem to work. You can get EJP here: http://ejp.sourceforge.net/ I've only run the tracer library in kaffe though, I ran the presenter interface using jdk1.4. thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Various fixes.
PatchSet 4001 Date: 2003/08/31 17:16:47 Author: guilhem Branch: HEAD Tag: (none) Log: Various fixes. Noticeable changes: Reimplementation of deleteOnExit (missing in classpath) The test case for this is not checked in (DeleteFile.java). Removed SoInterrupt because it is wrong. Why is it wrong? Improving test cases is desired over removing them. tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (jim): Fix -- only register network interfaces that have an IPv4 or IPv6 address.
PatchSet 4010 Date: 2003/09/02 00:53:58 Author: jim Branch: HEAD Tag: (none) Log: Fix -- only register network interfaces that have an IPv4 or IPv6 address. ... Its still kinda broken and a cursory look at the code shows that it doesn't quite match what the previous code was doing. Is there any reason the previous stuff needed to be overwritten? If it ain't broke... tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] bug report
Hi, hi, I was doing a make check on the latest CVS version of Kaffe and got the following error: ../kaffevm/.libs/libkaffevm.so: undefined reference to `softcall_illegalaccess' My bad, I'll get it in a sec. and the check failed. The architecture is PA-RISC and the OS is Debian. I don't really have any idea what this error is supposed to mean! Cheers, thomas tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Porting of Kaffe
I am part of a team porting Kaffe to a Cray. I would like to find someone who has an understanding of why the locks were implemented with hidden stack variable (the where in _lockMutex). It is causing great consternation in light of the Cray stack. Can you explain whats unique about the cray stack or give a pointer? It also seems rather hostile to someone trying to use a mutex, since it is not documented very well. I have changed locks to use a structure within locks itself and tracking the TID of the lock holder. Is there someone that could comment on this approach? Can you elaborate on this? The latte project, an offshoot of kaffe, have a superior lightweight lock implementation, rolling those in might be better. We are also finding that the debug code is not very friendly on an MP. The movement of data to the debug buffer is not protected by a mutex and, thus, becomes a difficult tool. Is there anyone that has ported Kaffe to an MP? dunno, but, I would imagine there are many many race conditions. Is there someone that could comment on this problem? Can you use the user-level threading implementation instead of native threads, atleast for now? George Blankenship tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Regarding labels !!
Akash Mahajan wrote: I meant the label structure defined in labels.h, something more simpler and understandable than what is written in that file. Which labels.h? The one in jit or jit3? And, what in particular don't you understand? tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: JavaLayer 0.3.0 works
Hi, just a quick heads up, since this his been a busy weekend getting applications to work: JavaLayer 0.3.0 works with kaffe from CVS. JavaLayer is a free software MP3 player, available at http://www.javazoom.net/javalayer/javalayer.html . It's quite fast, and takes about 18M to play a file on i686-linux-jit3. The threaded player works as well. The memory usage seems to come from jit-temp-data: Nr179 Mem 8980K, which doesn't get freed as it should be, so it's impossible to run with less then -mx 16M. I think the gc should try to free jit temp data when it runs out of memory. Tim, Helmer, what do you think? The GC doesn't track this, its kept around in a pool which isn't freed if it passes some threshold. cheers, dalibor topic tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Freeing jit temp data on demand (Was: Re: JavaLayer 0.3.0 works)
Timothy Stack wrote: Hi, The memory usage seems to come from jit-temp-data: Nr179 Mem 8980K, which doesn't get freed as it should be, so it's impossible to run with less then -mx 16M. I think the gc should try to free jit temp data when it runs out of memory. Tim, Helmer, what do you think? The GC doesn't track this, its kept around in a pool which isn't freed if it passes some threshold. So it would require either a change to the gc to track it (which I though it did, since the (re/de)allocations already happen through the gc interface) or a change in the jitter (jit3) to free temp data when it's not needed any more (after jitting a method? after a certain period of time?), right? I've changed it to free most of the pool after the jit has completed, can you cvs update and give it a go? cheers, dalibor topic thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
