Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8198418

Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

    XMLWordPrintable

Details

    • b02
    • generic
    • generic

    Description

      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/

      Attachments

        Issue Links

          Activity

            People

              redestad Claes Redestad
              redestad Claes Redestad
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: