[kaffe] GNU Classpath java.util.zip patch - To Merge Or Not To Merge

[Dalibor Topic]

Hi,

I looked into the performance of the zip replacement
patch, that replaces the native java.util.zip
implementation in kaffe by classpath's pure java
solution. I'm using compilation of Java classes with
kjc as my only benchmark, so your mileage wiull vary,
depending on your application.

As I've said before, the slowdown effect of using pure
java is negligible when I'm compiling kaffe's class
library on i386-linux with ji3 on a p3-650mhz. It's
about 2 % slower. The patch also allows kaffe to pass
about 80 new test cases on cygwin, making it actually
somewhat useable ;) I was interested in seeing how it
behaves on embedded/restricted systems, especially
those platforms without a stable jit (which means arm,
and maybe mips). I'm using the latest java.util.zip
source from GNU Classpath, so it includes the
optimizations that my patch on
http://www.kaffe.org/~robilad doesn't .

I compiled kaffe from cvs from 2002-12-17 with intrp
and jit, with native and pure java zip. I've used kjc
from a precompiled kaffe-1.0.7 with jit to build
kaffe-1.1.x-cvs versions using jit. 

I've tried running SciMark2 and FhourStones2
benchmarks on the interpreter engines, but both have
been quite pointless: they take forever, and they are
doing mostly work in memory, without accessing zip
files. For such applications the patched version
should yield quite the same results.

So I've settled for compilation using kjc as my
benchmark, as kjc is a big application, which accesses
zip files a lot. As I've explained above, when
compiling large source trees, like kaffe's class
library, on i386-linux the difference is ~2%. It's
more interesting when we are working with smaller
source trees, testing application startup times. I've
always had top -d 1 | grep kaffe running in the
background to be able to see total memory size used.

I've first compiled the FhourStones sources with kjc
2.1B.

* cvs-intrp-nativezip
time: 1 min 21 sec     total mem:  8136 KB

* cvs-intrp-javazip
time: 6 min 19 sec     total mem: 14184 KB

* cvs-jit-nativezip
time: 0 min 25 sec     total mem: 10860 KB

* cvs-jit-javazip
time: 1 min 11 sec     total mem: 16064 KB

* 107-jit (i.e. nativezip)
time: 0 min 24 sec     total mem: 13676 KB

As you can see, using java zip to compile a small set
of files results in big increase in used memory ~ 6
MB. The native zip version is between 3 ~ 4 times
faster. It takes more than three minutes before kjc
starts compiling when running on cvs-intrp-javazip. A
lot of that time seems to be spent collecting garbage.
When using jit and javazip, the difference melts down
a bit, but it still takes about 40 seconds before kjc
starts compiling. So using the pure java zip seems to
be bad news when you have an application that needs to
load fast. Also interesting to note is that memory
requirements to compile FhourStones when using jit and
nativezip seem to have decreased by 3 MB since 1.0.7 .

Next thing I compiled is classpath's
java/util/zip/*.java sources. I've left the
interpreter out of the picture, as I didn't want to
wait too long. I assume that someone will fix the jit
on those systems where it is apparently unstable.

* cvs-jit-nativezip
time: 1 min 05 sec     total mem: 15056 KB

* cvs-jit-javazip
time: 1 min 51 sec     total mem: 17372 KB

Here you can see that as the application starts to do
more work, instead of being busy loading classes, the
difference between the two implementations melts down.

Then I compiled kaffe's java.io.*.java files.

* cvs-jit-nativezip
time: 1 min 37 sec     total mem: 16088 KB

* cvs-jit-javazip
time: 2 min 25 sec     total mem: 18888 KB

I also measured in this case the difference in amount
of time spent jitting. ~ 30 sec for javazip and ~ 21
sec for nativezip.

finally, as a "large" work set, I compiled
java/[a-i]*/*.java from kaffe's class library.

* cvs-jit-nativezip
time: 4 min 57 sec     total mem: 24460 KB

* cvs-jit-javazip
time: 5 min 57 sec     total mem: 27092 KB

You can see that there is about one minute of
difference left. The java implementation is closing in
on the native one.

I've also tried to optimize the java.util.zip classes
by compiling them with -O9.

Here are the results when compiling java.util.zip

* cvs-jit-javazip-09
time: 1 min 52 sec     total mem: 17408 KB

didn't really help.

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.

Given these numbers, I don't think I should merge it
in as it is without some performance improvements. I'd
be glad if someone could investigate further. I've had
enough of embedded systems and cygwin for now ;)

Unfortunately, -prof doesn't work on arm-linux, so I
can't really tell which part of java.util.zip is a
performance hog.

If you're an embedded or cygwin developer/user, I'd
like to hear your opinion.

best regards,

dalibor topic

Additional notes: 

* using a pure java zip implementation decreases the
total installation size on arm-linux with intrp by
about 50k.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com