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

Hello everyone!

We've been bad at blogging here for a while. Apologies 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 provide enough compile time information to easily generate performant code. This is why, for 8u40, we have redesigned the Nashorn Type System, to produce better, faster code.  The output of the Nashorn compiler, Java byte code, is by design strongly typed and JavaScript isn't. There are significant problems translating a dynamic language AST to optimal bytecode. Attila Szegedi, Hannes Wallnöfer and myself have spent significant time researching and implementing a solution to this problem over 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

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.

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

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 solidify 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 of 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 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 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 find interesting:

Join the discussion

Comments ( 13 )
  • Rubin Saturday, December 13, 2014

    Good work! Congratulations. Impressive benchmark scores.

    Is there any chance some of those optimizations will eventually contribute to the excellent Bck2Brwsr or DoppioJVM projects? Do you know if there's any ongoing effort within Oracle to create a JVM in Javascript, for a true plugin-less Java experience in the browsers? (I know that's only indirectly related to this article.)

    I don't know a better solution to reach the sprawling client base - Android, iOS, Winphone etc., none of which have a true java implementation.


  • Brett Wooldridge Saturday, December 13, 2014

    Great work guys! We are just starting to leverage Nashorn, and this great news to us.

  • jay Saturday, December 13, 2014

    is the API to the continuations feature accessible? and how simple is simple? will it be documented upon release?

    that single sentence tickled me greatly, I make heavy use of rhino continuations but I would love to have an upgrade path into nashorn.

  • jlaskey Tuesday, December 16, 2014

    Continuations will be exposed in the ES6 work for JDK 9.

  • Pietro Braione Tuesday, December 16, 2014

    How does Nashorn compare with Truffle/JS?

  • lagergren Tuesday, December 16, 2014

    Jay - we are not exposing the continuations right now, but we really do want to create a multilanguage platform out of this, so hopefully this is the direction we are going for 9 and the future.

  • Anirvan Wednesday, December 17, 2014

    Nice work !!

    P.S. The is a broken image link before this statement: "To run Nashorn with 8u40 and optimistic types, use the argument --optimistic-types=true"

  • guest Wednesday, December 17, 2014

    V8 directly compiles to native code. Nashorn has an additional first step by generating bytecode first. How costly is creating bytecode first compared to the V8 compiler?

  • Matt Wednesday, December 17, 2014

    Exciting stuff! Are these improvements included in 8u40 Build b18?

  • Pete Thursday, December 18, 2014

    How does this approach compare/overlap with Project Graal and Truffle?

    Just curious as naively the descriptions of the optimizations present in Nashorn 8u40 seem similar to Project Graal (or more specifically Truffle).

    You talk of Nashorn becoming a 'LLVM for dynamic languages on the JVM', JRuby currently has a Graal/Truffle enabled implementation:


    My naive understanding is that Graal is a JIT compiler implemented in Java (i.e. not presently in JDK 8 or likely to be in JDK 9, and so not available to Nashorn), Truffle requires this Graal enabled VM and seems to be where the greatest possible overlaps with Nashorns LLVM aspirations lie.

  • Guest Wednesday, January 7, 2015

    Very interesting - hadn't realized that the Nashorn work was not just JS specific.

    It feels like the Dart language would be a good target for an additional language.

    Then I'd get the best of both worlds - the world class server VM with world class broad and deep libraries ( inbuilt and third party ), and a single decent ( not current JS - sorry ) language that works both on the web client and the server.

    If Google can co-opt Java for Android, I don't see why Oracle can't co-opt Dart :-)

    It also would be interesting to see a comparison of the Dart language VM speed versus this approach as I believe Dart VM doesn't actually use the optional type information.

  • Martin Wednesday, January 21, 2015

    "Nashorn TypeScript is still not open sourced, but we hope we have the chance to do it soon."


    Wow, never thought that there is s.th. like this in the works. We invest heavily into TypeScript, and so far, its the best way to write secure and maintainable "JS" code. This becomes a matter if you have large code bases. Our current solution using the TS transpiler feels bumpy, so I'm looking forward to the TS support in Nashorn. Thanks.

  • Cameron Taggart Friday, December 18, 2015

    It would be really awesome if Nashorn TypeScript got open sourced! Any progress? It would be great for both the TypeScript and Java/Scala communities. The TypeScript issue requesting this is https://github.com/Microsoft/TypeScript/issues/1789

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content


Integrated Cloud Applications & Platform Services