Re: [kaffe] java.lang.reflect.Method virtual method call bug (CVS)
Hi-- Helmer Krämer wrote: On Sat, 28 Dec 2002 00:55:45 +0100 Benja Fallenstein [EMAIL PROTECTED] wrote: It fixes the previous issue-- thanks! Cool. So we've got jython working with kaffe, then? I guess yes. But I can't really say: Before, the interpreter started up but would give these strange errors on some method calls sometimes. It still starts up, and the method call issue seems to be fixed, but that's not to say more bugs will not turn up, of course :-) But then, of course you can never know whether there's another bug. I'll tell if we stumble over one... Gzz still doesn't start; I get a java.lang.VerifyError: No code attribute for gzz/client/GraphicsAPI.startUpdateManager. Obviously, since the code never progressed this far before, I have no idea what's causing this, yet. We'll see. Well, there had to be something wrong with my patch ;) :-) Your patched kaffe/kaffevm/support.c should contain a function called findMethodFunc. If you modify this function like this: ... does gzz work then? Not completely; it starts up, but something in our call hierarchy eats simple key events like single characters, spaces or returns; more complex things like function keys, Tab or PgUp/PgDn are processed correctly. We do recieve the events, apparently, but something eats them. I haven't seen this on the proprietary JVMs, so I guess there must be some kind of incompatibility (trying to process key events across Javas is **icky**). I'll tell if I find out what's causing this. - Benja ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] java.lang.reflect.Method virtual method call bug (CVS)
Benja Fallenstein wrote: Cool. So we've got jython working with kaffe, then? I guess yes. But I can't really say: Before, the interpreter started up but would give these strange errors on some method calls sometimes. It still starts up, and the method call issue seems to be fixed, but that's not to say more bugs will not turn up, of course :-) But then, of course you can never know whether there's another bug. I don't suppose there's a Python regression test suite... that would sure help flush out any bugs. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Benchmarking kaffe using Ashes
Hi, attached you'll find my attempt at writing a FAQ entry for using the Ashes benchmark suite to test the performance of kaffe. I hope this helps people without access to (or need for) SPEC JVM 98 evaluate kaffe's performance better, and helps us get more reproducible numbers for decisions regarding performance. Of course, if someone could put up a nightly performance test server that fires off a mail to me with the results, I'd be very happy ;) best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Benchmarking Kaffe using Ashes == Author: Dalibor Topic [EMAIL PROTECTED] Introduction Q: What is Ashes ? A: Ashes is a freely redistributable collection of Java benchmarks and shell scripts. Q: Where can I get it ? A: Ashes is available for download at: http://www.sable.mcgill.ca/software Installation You'll need to download ashesBase-21Mar2000.tar.gz and ashesSuiteCollection.tar.gz and unpack them in a directory. Then you need to set a few environment variables. How you set environment variables depends on your shell. It's export VAR=value in bash. Use absolute paths because some Ashes scripts will fail when you use relative paths. ASHES_SUITE_COLLECTION=/absolute-path-to/ashesSuiteCollection CLASSPATH=/absolute-path-to/ashesBase/classes/ ASHES_JDK_CLASSES=/abolute-path-to-installed/kaffe/jre/rt ASHES_PDS=: PATH=$PATH:/absolute-path-to/ashesBase/bin Read the file index.html in the ashesBase directory for more information on installing and using Ashes. Benchmarking Before you start, you need to make sure that the java command actually invokes kaffe on your system. If it doesn't, set PATH=/absolute-path-to-installed/kaffe/bin:$PATH You need to copy a benchmark from the Ashes suite collection to the current directory first. I'll use achesEasyTestSuite in this example. Look into ashesSuiteCollection/suites for more test suites. refreshSuite ashesEasyTestSuite You should have an ashesEasyTestSuite directory in your current directory now. applyCmdOnSuite executeBenchmark ashesEasyTestSuite runs each benchmark exactly once. You can check if your checkout works that way. You should not get any *** Warning: Benchmark ran incorrectly! *** messages. If you do, please make sure that java invokes kaffe. java -fullversion will give you information on kaffe. Now that you've got the benchmark set up, you can do some real benchmarking. timeBenchmark runs a benchmark ten times and prints the results. applyCmdOnSuite timeBenchmark ashesEasyTestSuite results.txt
Re: [kaffe] java.lang.reflect.Method virtual method call bug (CVS)
Dan Kegel wrote: Benja Fallenstein wrote: Cool. So we've got jython working with kaffe, then? I guess yes. But I can't really say: Before, the interpreter started up but would give these strange errors on some method calls sometimes. It still starts up, and the method call issue seems to be fixed, but that's not to say more bugs will not turn up, of course :-) But then, of course you can never know whether there's another bug. I don't suppose there's a Python regression test suite... that would sure help flush out any bugs. I have absolutely no idea :-) -- there might be. -b. ___ 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-used event objects (was: Re: [kaffe] java.lang.reflect.Methodvirtual method call bug (CVS))
Benja Fallenstein wrote: Not completely; it starts up, but something in our call hierarchy eats simple key events like single characters, spaces or returns; more complex things like function keys, Tab or PgUp/PgDn are processed correctly. We do recieve the events, apparently, but something eats them. I haven't seen this on the proprietary JVMs, so I guess there must be some kind of incompatibility (trying to process key events across Javas is **icky**). I'll tell if I find out what's causing this. I have isolated the incompatibility: Kaffe re-uses KeyEvent objects; after issuing a KEY_PRESSED event, it issues a KEY_TYPED event which is the same object, with a field value changed inside. Interestingly, the KEY_RELEASED events seem to be separate objects. Gzz implements its own event queue to coordinate event processing with animation; this is implemented by putting the KeyEvent objects in a LinkedList. As it happens, Gzz by default only reacts to KEY_TYPED events, and as it happens, all three KEY_* events are usually queued before any of them is processed. This means that at the time we get around to processing the key events, we have two KEY_TYPED and one KEY_RELEASED event in the queue (because the original KEY_PRESSED event was changed to KEY_TYPED by Kaffe). Gzz might be able to work around this, but I suggest that Kaffe not re-use KeyEvent objects, as code like the above works fine on the proprietary Javas and breaks on Kaffe in nonobvious ways. (Caching by using weak references might be an option, but I wouldn't think it's worth it...) - Benja ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: GNU Classpath java.util.zip patch - To Merge Or Not To Merge
Hello all, Dalibor wrote: What conclusions should we draw? Here are mine: * pro: - fixes large bunch of cygwin problems - works without much slowdown on i386-linux-jit3 * contra: - delays program startup on arm-linux-jit by at least 30 seconds. - delays program startup on arm-linux-intrp by more than a minute. - uses more memory than native zip solution, between 2~6 MB. ...snip... If you're an embedded or cygwin developer/user, I'd like to hear your opinion. Won't hurt anything on x86. I can't use it for my mipsel-linux pda. Even 2Mb is way to much memory for me to sacrifice. Bear in mind I'm on a Helio, a lower end pda from a few years ago. I'm not sure what current platforms have available. Mark _ The new MSN 8: smart spam protection and 3 months FREE*. http://join.msn.com/?page=features/junkmailxAPID=42PS=47575PI=7324DI=7474SU= http://www.hotmail.msn.com/cgi-bin/getmsgHL=1216hotmailtaglines_smartspamprotection_3mf ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Re-used event objects (was: Re: [kaffe] java.lang.reflect.Methodvirtual method call bug (CVS))
Reading java/awt/KeyEvt.java, it seems like only events in the java.awt.Defaults.RecycleEvents bitmap should be re-used, but I can't see anything in the Kaffe source that would set RecycleEvents to anything but zero. What's going on? Thanks, - Benja Benja Fallenstein wrote: Benja Fallenstein wrote: Not completely; it starts up, but something in our call hierarchy eats simple key events like single characters, spaces or returns; more complex things like function keys, Tab or PgUp/PgDn are processed correctly. We do recieve the events, apparently, but something eats them. I haven't seen this on the proprietary JVMs, so I guess there must be some kind of incompatibility (trying to process key events across Javas is **icky**). I'll tell if I find out what's causing this. I have isolated the incompatibility: Kaffe re-uses KeyEvent objects; after issuing a KEY_PRESSED event, it issues a KEY_TYPED event which is the same object, with a field value changed inside. Interestingly, the KEY_RELEASED events seem to be separate objects. Gzz implements its own event queue to coordinate event processing with animation; this is implemented by putting the KeyEvent objects in a LinkedList. As it happens, Gzz by default only reacts to KEY_TYPED events, and as it happens, all three KEY_* events are usually queued before any of them is processed. This means that at the time we get around to processing the key events, we have two KEY_TYPED and one KEY_RELEASED event in the queue (because the original KEY_PRESSED event was changed to KEY_TYPED by Kaffe). Gzz might be able to work around this, but I suggest that Kaffe not re-use KeyEvent objects, as code like the above works fine on the proprietary Javas and breaks on Kaffe in nonobvious ways. (Caching by using weak references might be an option, but I wouldn't think it's worth it...) - Benja ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
