RFR: Faster ZipFile.getEntry()/entries()

[Xueming Shen]

Hi,

The change proposed here is to bring the zip entry handing code from the 
native
level to the java level. This effectively solves the performance issues 
of ZipFile.getEntry
and entries() that is caused by multiple jni invocation steps to 
generate one single
ZipEntry (see ZipFile.getZipEntry()). A simple non-scientific benchmark 
test of simply
iterating the ZipFile via the Enumeration from entries() on 
rt.jar/charsets.jar suggests
a 50%+ speed boost.

http://cr.openjdk.java.net/~sherman/zipfile_j/webrev

Couple notes:

(1) Ideally it might be desired to go further to bring all the native 
code of ZipFile to
java level (which should help completely remove that mmap crash issue, 
have better
file and memory management... ), but it is suggested that it might be 
better to limit
the scope of the change at this late release circle.

(2) JavaFile.read0() is the version that uses 
"getPrimitiveArrayCritical" to read file bits
into the java array directly (instead of using a stack buffer and then 
copy into the
java array), which appears to be 5% faster. But I can't make up my mind 
of which one
would be better. Given (1) the trouble we had before in De/Infalter code 
(when the
getPrimitiveArrayCritical is being heavily used), (2) FileInputStream 
uses the same
"copy" approach, I'm staying with the "copy" appraoch, but option 
appreciated.

(3) We will have to keep the native implementation (zip_util.c) for the 
vm directly
access.

Thanks!
-Sherman