CODEWITHSUNDEEP
javajava-9nashornjava-10
Max Tardiveau
Max Tardiveau

Reputation: 193

Nashorn performance on JDK 9 and JDK 10

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?

Upvotes: 16

Views: 958

Answers (1)

David Conrad
David Conrad

Reputation: 16379

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.

Upvotes: 15

Related Questions