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?
With the release of Java 11, Nashorn was deprecated citing challenges to maintenance, and has been removed from JDK 15 onwards. Nashorn development continues on GitHub as a standalone OpenJDK project and the separate release can be used in Java project from Java 11 and up.
The Nashorn engine is included in the Java SE Development Kit (JDK). You can invoke Nashorn from a Java application using the Java Scripting API to interpret embedded scripts, or you can pass the script to the jjs or jrunscript tool. Note: Nashorn is the only JavaScript engine included in the JDK.
Nashorn: Nashorn is a JavaScript engine which is introduced in JDK 8. With the help of Nashorn, we can execute JavaScript code at Java Virtual Machine. Nashorn is introduced in JDK 8 to replace existing JavaScript engine i.e. Rhino.
While the Nashorn team didn't have time to deliver the complete ES6 feature set for the JDK 9 release, more ES6 features will follow in future updates. To activate ES6 support, use --language=es6 on the command line.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With