-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
b02
-
generic
-
generic
A small regression to lambda bootstrapping came in with the recent condy merge, and it took a while to figure out why.
Before condy, the first three parameters of calls from the BSM invoker to the six parameter LMF::metafactory were statically known, so fourth through sixth param were being dynamically bound to add casts at runtime (MH.invoke -> MH.asType(MT) -> MHI.makePairwiseConvertByEditor -> generates a slew of filterArguments, rebinds etc)..
With condy, the 3rd parameter is now an Object of either Class or MethodType, thus not statically known. This means the MethodType sent to checkGenericInvoker have to add a cast for the third param too, thus when running through MH.asType -> makePairwiseConvert we see an additional rebind, some additional time spent spinning classes etc. Effectively increasing the cost of first lambda initialization by a small amount (a couple of ms)
Here comes the realization that much of the static overhead of the lambda bootstrapping could be avoided since we can determine and cast arguments statically for the special case of LambdaMetafactory::metafactory and even call bootstrapMethod.invokeExact. This might be a hack, but a hack that removes a large chunk of the code executed (~75% less bytecode) for the initial lambda bootstrap, and reduces the number of classes loaded and generated substantially. Startup tests show an ~12ms improvement on my machine.
http://cr.openjdk.java.net/~redestad/8198418/jdk.02/
Before condy, the first three parameters of calls from the BSM invoker to the six parameter LMF::metafactory were statically known, so fourth through sixth param were being dynamically bound to add casts at runtime (MH.invoke -> MH.asType(MT) -> MHI.makePairwiseConvertByEditor -> generates a slew of filterArguments, rebinds etc)..
With condy, the 3rd parameter is now an Object of either Class or MethodType, thus not statically known. This means the MethodType sent to checkGenericInvoker have to add a cast for the third param too, thus when running through MH.asType -> makePairwiseConvert we see an additional rebind, some additional time spent spinning classes etc. Effectively increasing the cost of first lambda initialization by a small amount (a couple of ms)
Here comes the realization that much of the static overhead of the lambda bootstrapping could be avoided since we can determine and cast arguments statically for the special case of LambdaMetafactory::metafactory and even call bootstrapMethod.invokeExact. This might be a hack, but a hack that removes a large chunk of the code executed (~75% less bytecode) for the initial lambda bootstrap, and reduces the number of classes loaded and generated substantially. Startup tests show an ~12ms improvement on my machine.
http://cr.openjdk.java.net/~redestad/8198418/jdk.02/
- relates to
-
JDK-8198490 java/util/logging/TestLogConfigurationDeadLock.java timed out.
- Closed
-
JDK-8198492 Bootstrapping java.lang.invoke can cause deadlock after JDK-8198418
- Closed
-
JDK-8198523 Refactor BootstrapMethodInvoker to further avoid runtime type checks
- Resolved