RFR(s): 8244659: Improve ZipFile.getInputStream

[Martin Buchholz]

On Tue, May 12, 2020 at 6:42 AM Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi Volker,
>
> I think this look like a nice improvement!
>
> One high-level concern I have with the design is that this will add and
> retain (at least) one 64k buffer to each Jar-/ZipFile we've read a
> stream from. We routinely see apps reading classes from 100s of jar
> files on their class path, so this could add noticeable overhead to the
> baseline retained memory usage of such applications.
>

At Google, it's common to run java applications with 10,000 small jar files
on the classpath.
Making the "quiescent cost" of each ZipFile object as small as possible is
important.
OTOH we currently retain the byte[] of the zip file central directory
indefinitely.



>
> Have you considered other strategies such as making the cache global?
> Since a (the?) common usage pattern is likely a single thread repeatedly
> reading resources from a series of jar files, contention on such a
> global cache is likely going to be very low, while likely reducing the
> total number of buffers we have to allocate and retain to single-digit
> numbers. I don't insist on a re-design, but it shouldn't be hard to
> prototype and run some numbers on it.
>

Java resource management is still hard!