Nashorn 在 JDK 9 和 JDK 10 上的表现
Nashorn performance on JDK 9 and JDK 10
如果您在 JDK 8 上使用 Nashorn 解释 moment.js 库，它会在几秒钟内运行：
time .../JDK8/bin/jjs moment-with-locales-2.22.2.js
real 0m2.644s
user 0m10.059s
sys 0m0.287s
但是在 JDK 9 或 10 上做同样的事情，这很糟糕：
time .../JDK10/bin/jjs moment-with-locales-2.22.2.js
real 0m27.308s
user 0m59.690s
sys 0m1.353s
这实际上慢了十倍。只有我吗？
我知道 Nashorn 将被弃用，但它在受支持的情况下是否不能正常工作？
有什么建议吗？解决方法？
Nashorn 可以使用 'optimistic types'（详见下文），它们在 Java 9 及更高版本中默认打开，但它们会导致启动延迟。
关闭乐观类型产量：
$ time jjs --optimistic-types=false moment-with-locales.js
real 0m4.282s
user 0m0.000s
sys 0m0.015s
开关可以简写-ot=false.
jjs -h定义乐观类型如下：
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.
因此，从长远来看，乐观类型可能会产生更快的性能（尽管不能保证），但会导致启动速度变慢。
如果您在 JDK 8 上使用 Nashorn 解释 moment.js 库，它会在几秒钟内运行：
time .../JDK8/bin/jjs moment-with-locales-2.22.2.js real 0m2.644s user 0m10.059s sys 0m0.287s
但是在 JDK 9 或 10 上做同样的事情，这很糟糕：
time .../JDK10/bin/jjs moment-with-locales-2.22.2.js real 0m27.308s user 0m59.690s sys 0m1.353s
这实际上慢了十倍。只有我吗？
我知道 Nashorn 将被弃用，但它在受支持的情况下是否不能正常工作？
有什么建议吗？解决方法？
Nashorn 可以使用 'optimistic types'（详见下文），它们在 Java 9 及更高版本中默认打开，但它们会导致启动延迟。
关闭乐观类型产量：
$ time jjs --optimistic-types=false moment-with-locales.js
real 0m4.282s
user 0m0.000s
sys 0m0.015s
开关可以简写-ot=false.
jjs -h定义乐观类型如下：
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.
因此，从长远来看，乐观类型可能会产生更快的性能（尽管不能保证），但会导致启动速度变慢。