[10!] RFR: 8193471: Startup regression due to JDK-8185582 (original) (raw)

Xueming Shen xueming.shen at oracle.com
Wed Dec 13 21:44:57 UTC 2017

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

More information about the core-libs-dev mailing list