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.