[10!] RFR: 8193471: Startup regression due to JDK-8185582
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
+1 Paul.
On 13 Dec 2017, at 11:36, Claes Redestad <claes.redestad@oracle.com> 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
Looks good Thanks, Roger On 12/13/2017 2:36 PM, 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
fyi Google does some automated desugaring for lambdas using a program named ... desugar.
Lambdas and their overheads isn't much of an issue in the grand scheme of things, but forcing the initialization early when not much of the code java.lang.invoke depends on has had a chance to at least warm up somewhat does cause awkward hiccups in startup tests. Thus it makes sense to defer the first initialization somewhat, for now. I hope we'll continue making these overheads smaller so that we in time can use lambdas (or any new language feature) anywhere without regressing even the most synthetic startup tests. /Claes On 2017-12-13 21:17, Martin Buchholz wrote:
fyi Google does some automated desugaring for lambdas using a program named ... desugar.
It's a trade off, desugaring lambdas has several drawbacks, the main one being the desugared class being not unloaded even if the lambda instance is no more accessible. Also, it takes more space on disk, and captured values are not considered as really final by the JIT. You gain a faster startup (usually, it depends how it's desugared exactly) and you do not need a VM that supports invokedynamic*. Rémi * but given that string concatenation in 9, records and pattern matching in the future will also use invokedynamic, at some point your VM will need to support invokedynamic. ----- Mail original -----
De: "Martin Buchholz" <martinrb@google.com> À: "Claes Redestad" <claes.redestad@oracle.com> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Mercredi 13 Décembre 2017 21:17:30 Objet: Re: [10!] RFR: 8193471: Startup regression due to JDK-8185582
fyi Google does some automated desugaring for lambdas using a program named ... desugar.
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
participants (6)
-
Claes Redestad
-
Martin Buchholz
-
Paul Sandoz
-
Remi Forax
-
Roger Riggs
-
Xueming Shen