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

    • Sub-task
    • Resolution: Fixed
    • P3
    • 9
    • 8u40
    • core-libs
    • b36
    • generic
    • 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

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

                Dates

                  Created:
                  Updated:
                  Resolved: