Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand

Neil Richards neil.richards at
Sat Apr 9 00:04:29 UTC 2011

Hi David,

You are correct that the ZipFileInflaterInputStream code is not inherently
thread-safe (without user synchronization), but then, the contract of
InputStream does not require it to be (as Sherman previously observed on
this thread).

The previous suggested fix caused ZFIIS to interact with the finalize
thread, thus it had to care about being thread-safe at least to the extent
of safe-guarding that interaction.

As Sherman observed, and I agreed, finalization on that object is not really
needed, so the inherent cross-thread interaction that would be introduced by
the finalize method can be avoided in that case, and so the need to cater
for inherent thread-safety can likewise be avoided.

With the latest suggested change, if the ZFIIS is driven by multiple
threads, it will be done at the user's (developer's) behest, so the user can
(should) know to implement suitable synchronization to ensure correct

Therefore, I believe the same lack of synchronization in ZFIIS as there was
in the previous anonymous inner class to be entirely justified in this case,
given that it no longer has a finalize() method.

Please let me know if you still disagree with this assessment,

(Sent from my phone, so probably missing my usual signature)

More information about the core-libs-dev mailing list