[kaffe] Fixing Cygwin port using Classpath's pure Java java.util.zip

Mark Wielaard mark@klomp.org
12 Dec 2002 17:44:08 +0100


Hi,

On Thu, 2002-12-12 at 17:11, Dalibor Topic wrote:
> Fortunately, GNU Classpath provides a pure java
> implementation of java.util.zip. I decided to merge it
> in and see if that would work better. In short, it
> does, and reduces the number of test case failures to
> 34. Nothing crashes during compilation. One failure is
> probably a bug in Classpath's implementation of Zip
> file date handling (DosTimeVerify).

If you have a test case please file a bug report.
<https://savannah.gnu.org/bugs/?group=classpath>

> The best way to solve this circular dependency
> problem, is to avoid using getResource altogether
> inside CharacterProperties. I replaced the binary
> files holding the character properties database by two
> class files with byte arrays. That unfortunately
> increased the size of the database files by around 40
> KB, or a factor of 10. The problem with using byte
> arrays is that they are initialized *manually* by the
> VM at runtime, so the compiled class file contains a
> long statical initializer method. I'd like to hear
> about better methods for storing binary data in class
> files.

Try storing them as Strings and then get the char bytes.
For inpiration see GNU Classpath scrips/unicode-muncher.pl,
gnu/java/lang/CharData.java and the zeroBasedString() method in
java/lang/String.java. UTF8 Strings can be stored more efficiently in
class files.

> That was the good news. The bad news is that I'm
> afraid of performance issues when using the pure java
> zip library from GNU Classpath. There is small
> difference when I compile kaffe's class library using
> kjc. With Classpath's zip libraries, it's 148 seconds,
> with kaffe's code it's 144 seconds on my p3-650 mhz
> notebook. I don't think the difference is worth
> delaying the patch. But on platforms without a jit,
> the difference *might* be much higher.

Make sure that you get the latest version from CVS I recently made some
changes that should speedup java.util.zip.ZipFile a bit and made reading
zip files a little bit "lazier". For Kissme, which doesn't have a JIT,
these made a huge difference. See:
http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipFile.java
There is some room to make it even more efficient and more lazy.
More efficient by reading from the file in bigger chunks. Lazier by
deferring reading a zip file entry till it is really needed.

Cheers,

Mark