RFR(s): 8244659: Improve ZipFile.getInputStream

[Claes Redestad]

On 2020-05-12 16:07, Martin Buchholz wrote:
> 
> 
> On Tue, May 12, 2020 at 6:42 AM Claes Redestad 
> <claes.redestad at oracle.com <mailto: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.

Ouch! That could mean a 600Mb+ footprint increase. Not very nice.

> 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.

Striking the right trade-off is hard - and footprint has often gotten
the shortest stick.

> 
> 
>     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!

... but fun?!

/Claes