Nashorn performance on JDK 9 and JDK 10

  • A+
Category:Languages

If you interpret the moment.js library using Nashorn on JDK 8, it runs in a couple of seconds:

 time .../JDK8/bin/jjs moment-with-locales-2.22.2.js real    0m2.644s user    0m10.059s sys     0m0.287s 

But do the same on JDK 9 or 10, and it's terrible:

 time .../JDK10/bin/jjs moment-with-locales-2.22.2.js real    0m27.308s user    0m59.690s sys     0m1.353s 

This is literally ten times slower. Is it just me?

I know Nashorn is going to be deprecated, but should it not work properly while it is supported?

Any suggestions? Workarounds?

 


Nashorn can use 'optimistic types' (more below), and they are turned on by default in Java 9 and later, but they cause delays at startup.

Turning off optimistic types yields:

$ time jjs --optimistic-types=false moment-with-locales.js real    0m4.282s user    0m0.000s sys     0m0.015s 

The switch can be abbreviated -ot=false.

jjs -h defines optimistic types as follows:

Use optimistic type assumptions with deoptimizing recompilation. This makes the compiler try, for any program symbol whose type cannot be proven at compile time, to type it as narrow and primitive as possible. If the runtime encounters an error because symbol type is too narrow, a wider method will be generated until steady stage is reached. While this produces as optimal Java Bytecode as possible, erroneous type guesses will lead to longer warmup. Optimistic typing is currently enabled by default, but can be disabled for faster startup performance.

Thus, optimistic typing may yield faster performance in the long term (though that is not guaranteed), but results in slower startup.

Comment

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: