Type transitions in the optimistic type system
Another novelty in 8u40 is that Nashorn actually performs extensive intra-function static type analysis, so the generated code ends up being much better than in the above conservative scenario. It still can't prove all the types, though, and that's where optimistic type system comes in. Our optimistic type system works by assuming that any statically unprovable type is an int, the narrowest possible of all types. If this turns out to be wrong at runtime, e.g. we load a field from memory/scope that turned out to be an Object or a double instead, or if we perform a 32-bit addition that overflows, we will replace the executing code with a more conservative version, that is regenerated on the fly. Nashorn supports simple continuations to facilitate code replacement at runtime. This is a feature that can have multiple other uses in the future, for example going back and forth between a hypothetical interpreter layer and compiled bytecode.
Octane benchmark scores, normalized on JDK 8.
This makes the bytecode that we produce (when stable) contain optimal Java types for speedy execution. The cost for this (everything has a cost) is that we spend more time generating code, which affects things like warmup slightly negatively. Warmup is the major R &D area for JDK 9, and we are confident that we can solve this, and also customize the workload we give HotSpot to compile better, so that it spends its cycles much more optimally.
To run Nashorn with 8u40 and optimistic types, use the argument --optimistic-types=true. As we haven't had time to check in a solution to the warmup issues yet (it doesn't affect everything, but where issues remain it can be annoying), the optimistic type system is not yet the default behavior for Nashorn. This might be overly conservative, but we didn't want to break anyone's warmup unnecessarily.
Furthermore: Nashorn in JDK 8u40 also supports caching generated code and type information deduced at runtime to disk. This means that only the first iteration of a largish application with long warmup will be an issue. Consecutive runs of the same code will stabilize very quickly with the same good performance.
Please try it out and tell us what you find! If you have questions, please read the documentation and feel free to join the firstname.lastname@example.org list and talk to us. You can also follow the Nashorn team on Twitter:
We'll try to blog more here in the near future. Stay tuned and sorry for the hiatus.
P.S. If you are interested in the internal workings of the new type system or more information as the JVM as a polyglot multilanguage runtime and Nashorn as its facilitating framework, here are some links to presentations on the subject, that you may find interesting: