Nashorn Architecture and Performance Improvements in the Upcoming JDK 8U40 Release

Oracle

Blogs Home Products & Services Downloads Support Partners Communities About Login

Oracle Blog

Nashorn

JavaScript for the JVM.

Nashorn architecture and performance improvements in the upcoming JDK 8u40 release

By lagergren on Dec 12, 2014

Hello everyone!

We've been bad att blogging here for a while. Apologizes for that. I thought it would be prudent to talk a little bit about OpenJDK 8u40 which is now code frozen, and what enhancements we have made for Nashorn.

8u40 includes a total rewrite of the Nashorn code generator, which now contains the optimistic type system.

JavaScript, or any dynamic language for that matter, doesn't have enough statically available type information to provide performant code, just by doing compile time analysis. That's why we have designed the new type system to get around this performance bottleneck. While Java bytecode, which is the output of the Nashorn JIT, is strongly typed and JavaScript isn't, there are problems translating the AST to optimal bytecode. Attila Szegedi, Hannes Wallnöfer and myself have spent signiﬁcant time researching and implementing this the last year.

Background: Conservatively, when implementing a JavaScript runtime in Java, anything known to be a number can be represented in Java as a double, and everything else can be represented as an Object. This includes numbers, ints, longs and other primitive types that aren't statically provable. Needless to say, this approach leads to a lot of internal boxing, which is quite a bottleneck for dynamic language execution speed on the JVM. The JVM is very good at optimizing Java-like bytecode, and this is not Java-like bytecode. Type transitions in the optimistic type system

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 in 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.

We also specialize/guess how bytecode will look depending on what arguments are passed to a callsite at link time, with guards against these changing in the future.

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 research area for JDK 9, and we are conﬁdent that we can solve this, and also customize the workload we give HotSpot to compile better, so that it spends its cycles cycles much more optimally. The day only has 24 hours, though, so we started out with the performance framework.

In our efforts to turn Nashorn into a generic platform/runtime for dynamic languages for the JVM, the optimistic type system integrates nicely with whatever AST Nashorn is asked to generate code for. These plans will also solidy more for future Java releases, and we hope that Nashorn eventually will turn into a kind of "LLVM for dynamic languages on the JVM". The optimistic typing problem comes back to every dynamic language. To prove this, our excellent thesis student Andreas Gabrielsson has successfully implemented almost everything required to run TypeScript on Nashorn. At the time of this writing, modules in the only large feature missing. Nashorn goes directly to bytecode from TypeScript without generating JavaScript in a mid-level compiler tier. This is pretty awesome and shows how extensible Nashorn already is. We have thought about Ruby and Groovy running in a similar environment. Nashorn TypeScript is still not open sourced, but we hope we have the chance to do it soon.

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.

We can report several orders of magnitude on performance increase on things like the Octane benchmarks suite compared to previous releases. We can also report near native or native performance on the REST and HTTP benchmarks for the Avatar project. We feel pretty good about this. In several cases, JavaScript applications on Nashorn run as fast as the same application on a native runtime such as SpiderMonkey or v8. Needless to say, we are pretty proud of our work.

Furthermore: Nashorn in JDK 8u40 also supports caching generated code and type information deduced at runtime to disk. This means that only the ﬁrst 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 ﬁnd! If you have questions, please read the documentation and feel free to join the nashorn-dev@openjdk.java.net list and talk to us. You can also follow the Nashorn team on Twitter:

Jim Laskey: @wickund Sundararajan Athijegannathan: @sundararajan_a Marcus Lagergren: @lagergren Attila Szegedi: @asz Hannes Wallnöfer: @hannesw

We'll try to blog more here in the near future. Stay tuned and sorry for the hiatus.

Proudly yours, The Nashorn team through Marcus Lagergren (Dynamic language performance architect)

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 ﬁnd interesting:

Marcus Lagergren - GeekOut 2013 - The JVM as a multi language runtime Marcus Lagergren - JVMLS 2013 - Nashorn performance war stories and the optimistic type architecture Marcus Lagergren - Keynote, JAX 2013 - Why Dynamic Languages on the JVM matter Marcus Lagergren - JVMLS 2014 - Towards Native Performance with Dynamic Languags on the JVM Attila Szegedi - JVMLS 2014 - Dynamic Languages Toolchain on the JVM Attila Szegedi - StrangeLoop 2014 - Nashorn: implementing a Dynamic Language Runtime on the JVM in 2014

Category: Oracle

Tags: none

Permanent link to this entry

Comments: