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