Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8058884 Reconcile deoptimizing recompilation with code splitting
  3. JDK-8060241

Immediately invoked function expressions cause lot of deoptimization

    XMLWordPrintable

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 8u40
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b36
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        After implementing the optimistic splitter in JDK-8059844, we experienced that the time to run compile-octane-normal test for pdfjs octane test grew to 55 seconds (from 6 when splitter was non-noptimistic). An investigation pointed out that there's one function that we recompile 60(!) times; 'pdfjsWrapper$:split'. That's the main split portion of pdfjsWrapper function, and it's full of constructs like:

        var StatTimer = (function StatTimerClosure() {
         ...
         function StatTimer() {
           this.started = {};
           this.times = [];
           this.enabled = true;
         }
         ...
         return StatTimer;
        })();

        Basically, it's using anonymous function invocation to provide a private lexical closure for initializing a function. Now, our problem is that we'll invoke every such anonymous function with an optimistic call site that'll presume the return type of the function is an int (so first we'll try to treat StatTimer as int in the caller), which'll obviously fail.

        Now, this is something that's expected with optimistic compilation. We didn't run into this earlier since pdfjs was split, and splitter wasn't optimistic.

        We could run a local variable type analysis over such function expressions to figure out their return type. The analysis is not too costly. It's definitely cheaper than triggering a recompilation of the outer function. In the case above, static type analyzer would be able to infer that "return StatTimer" will be returning an object (a function object); we can use that to inform the caller to not emit an optimistic call site, thus sparing us a recompilation.

        Fixing this issue brought down pdfjs warmup from 55 seconds down to 14.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                attila Attila Szegedi
                Reporter:
                attila Attila Szegedi
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: