ZipInputStream brokenness

Sun Sep 1 10:49:00 GMT 2002

On 2002年8月31日, Jesse Rosenstock wrote:
> Adam> I suggested merging the classpath implementation:
> Adam> http://gcc.gnu.org/ml/java/2002-06/msg00023.html
>> I would vote for that, too (not that I get a vote). Does anyone have
> specific performance, correctness, memory usage, coding style or other
> objections?

There is a performance problem in both java.util.zip implementations:
unbuffered I/O. Running the small test case:
import java.io.*;
import java.net.*;
public class J {
 public static void main(String[] args) {
 try {
 URL url = new
URL("jar:file:/opt/gcc/share/java/libgcj-3.3.jar!/java/lang/Object.class");
 InputStream is = url.openStream();
 byte[] buf = new byte[8192];
 is.read(buf);
 } catch (IOException ex) {
 ex.printStackTrace();
 }
 }
}
under strace, I get:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 87.28 0.612733 9 65811 read
 7.18 0.050436 4 11976 lseek
 3.15 0.022138 5 4036 fstat
At least 2/3 of runtime is system call overhead. And this is on Linux.
It's far more noticeable on platforms with expensive syscalls (Solaris).
I don't see this penalty running an equivalent extract with e.g. fastjar.
I have no opinion w.r.t. correctness, though I haven't tested the
classpath code much. In particular I haven't been bitten by Adam's
problem yet, nor have I tried his testcase.
Speaking for myself, I don't see a win from merging the classpath code.
I'd rather spend time fixing the I/O.
Jeff