On 12/13/2017 11:36 AM, Claes Redestad wrote:
Hi,
another startup regression due to very early use of lambdas and method refs
that came in with JDK-8185582: Update Zip implementation to use Cleaner, not
finalizers
Webrev: http://cr.openjdk.java.net/~redestad/8193471/open.00/
/Claes
Maybe it's time to do a "de-lambda" for the In/Deflater/ZStream.
ZStream was a simple abstract to wrap the long address in the "old" day.
It did not need to know In/Deflater and it was perfectly fine to be shared
by Deflater and Inflater.
During the work of migrating from finalize() to Cleaner it appears to be
a good idea to leverage the ZStream itself to be a cleaner, so we don't
have to create a separate "cleaner" object. So it needs to know which
"end(long)" to call, and it appears a "LongConsumer" is perfect and
cheap approach. The LongSupplier for address is simply a "looks better"
(if my memory serves correctly. It might also have something to do with
the proposal of adding something into the Cleaner api...) With the
"fallback-to-finalize" code added later, it turns out the ZStream also needs
to know the "class" of the owner ...
Given the fact that we now have to create two objects for each Inflater
to workaround the startup "regression", I think it might be the time to stop
the sharing and to have separate ZStream for Inflater and Deflater, and
put the dedicated "ZStream" back into the Inflater/Deflater as a static
private class. We no longer need those lambda. The only cost is to have
some bytes for the "duplicated" classes in the storage?
http://cr.openjdk.java.net/~sherman/inf_desugar/webrev
opinion?
sherman
