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
Re: [kaffe] DefaultSerialization
Patrick Tullmann writes: In libraries/nativelib/clib/ObjectStreamClassImpl.c, the function findDefaultSerialization() tries to find an inner class named DefaultSerialization of any class it is trying to serialize. It seems that java.util.Hashtable, java.math.BigInteger, and java.awt.Component all use this inner class. It provides some sort of object-specific assistance to the serialization code. As far as I can tell, this is completely a Kaffe-specific construction. (Classpath's Component and Hashtable just serialize/deserialize themselves in a straightforward way. I can't find anything interesting on the web about a DefaultSerialization inner class as a hack for customization of serialization). I thought the whole point of adding DefaultSerialization to java.util.Hashtable was to make its serialization compatible with Sun's. I can't imagine this is Java-compatible (anyone who happens to have an inner class called DefaultSerialization will probably get surprising results). Perhaps its a hack that pre-dates some fixes Sun made to serialization? Anyone know anything about this? Probably.. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] DefaultSerialization
Archie wrote: I thought the whole point of adding DefaultSerialization to java.util.Hashtable was to make its serialization compatible with Sun's. I wouldn't be surprised, though, if the approach of using an inner class called DefaultSerialization has gone stale, and there are now better ways of making Kaffe's Hashtable compatible with Suns. Does anyone remember if Sun's VM ever at any point included a DefaultSerialization inner class which was magical? (I checked JDK1.4 and JDK1.3 --- just by using reflection, mind you. :) I guess I'll try fixing Hashtable to not use this magic inner class (and still be compatible with Sun's serialized classes). This exercise will probably make the motivation for DefaultSerialization obvious... -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Mean people suck. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] powerpc performance and speed
Hi Mat, --- Mathieu Dube [EMAIL PROTECTED] wrote: we're doing tests with kaffe on powerpc and according to the guys who did the tests kaffe with the interpreter since no jit is available would be 30 to 100 times slower than the sun vm. janosvm 0.8.0 includes an alpha version of the PowerPC jit3 back end for Mac OS X (darwin), you might want to take a look at it, and try to merge it with kaffe.org sources. best regards, dalibor topic __ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com ___ 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 [EMAIL PROTECTED] wrote: On Tuesday, September 17, 2002, at 10:52 PM, Patrick Tullmann wrote: 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... sparc-solaris and arm-linux use the old jit (it does not get through the class library compile on arm though). pocketlinux source tree includes jit3 versions for both, if someone wants to port it over to kaffe. cheers, dalibor topic __ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] DefaultSerialization
Stuart wrote: My guess is that these classes date back to when JDK1.1 was common. IIRC, at that point the only available serialization technique was to implement Serializable (and have your private instance variables directly yanked out from under you and dumped to disk) or to implement Externalizable I think this is right. Looking at the DefaultSerialization classes in java.awt.Component and java.math.BigInteger makes that pretty clear. The Hashtable serialization stuff must have been updated, though, since it was sort of using the now-standard readObject/writeObject. I've fixed Hashtable, Hashmap and BigInteger to use readObject/writeObject to generate sun-compatible serializations (haven't tested it too much yet, but I don't forsee any major problems). However, java.awt.Component has this note in it: While this is serializing something like what JDK expects, we don't handle the more complex things like Properties or popupMenus yet (because I'm not sure how to convert what we do into what they expect). So, I'm wondering if its worthwhile to update to readObject/writeObject, or if I can punt on sun-compatible Serialization for java.awt.Component? Do apps actually serialize AWT components? Unless someone hollers, I'm going to drop the awkward-and-incompatible Component serialization in favor of straightforwardly incompatible Component serialization. Also, if anyone has a clue about other types that should be tested for sun-serialization compatibility, let me know. Anyone feel like doing some CVS archeology and finding out when DefaultSerialization was introduced in Kaffe, and trying to determine which JDK release was current at the time? The BigInteger serialization stuff looks like its from April of `99, which is a good 4 months after JDK1.2 shipped (*). But, that could just be the date of the merge of pre-existing code from transvirtual's private Kaffe tree... (*) http://java.sun.com/features/2000/06/time-line.html -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] VR Cows are a medium rarely well done. -- someone in c.g.a ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] DefaultSerialization
I wrote:
I've fixed Hashtable, Hashmap and BigInteger to use
readObject/writeObject to generate sun-compatible serializations
(haven't tested it too much yet, but I don't forsee any major
problems).
Hah. I didn't fully understand how bizarre and complicated
serialization can get, and the problem is bit more complex. It turns
out the that right way to solve these problems is by using the
ObjectInputStream.GetField and ObjectOutputStream.PutField hackery.
However, none of that per-field serialization magic is implemented in
Kaffe. So, I'll just push the current work on my personal Kaffe
stack, and fix GetField/PutField
Anyone know if PocketLinux has any improvements to Kaffe's
serialization I should be looking at? (Also, any idea where to get a
pocketlinux source distro now that pocketlinux.{com,org} is gone?)
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
Research is not just an adventure, its a job.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
