Nashorn in JDK 8u40
marcus.lagergren at oracle.com
Wed Mar 4 16:25:00 UTC 2015
Extremely awesome summary, Attila.
We should probably mention the code cache and the optimization cache as well, which can speed up startup for consecutive runs of a large application by serializing code and optimization info to disk:
There is also, embarrassingly enough, a performance regression that Benjamin Winterberg spotted, having to do with operations on exactly one object and one primitive. Some specialization went away while we were implementing the optimistic type system. Luckily, there are multiple simple workarounds. Sorry about that. https://twitter.com/benontherun/status/573061256132886528 <https://twitter.com/benontherun/status/573061256132886528> - The issue is https://bugs.openjdk.java.net/browse/JDK-8035712
Several more smallish enhancements and regression fixes are targeted for 8u60. We wanted to put more effort on startup and warmup performance for the first run as well, not just by caching code, but the day only has 24 hours, so that will go into the next major release. The good news here is that we seem to have massive performance improvements on this coming along quite nicely.
> On 04 Mar 2015, at 00:20, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> Hi folks,
> JDK 8u40 was released today, and I wanted to take a moment to summarize some of the new stuff in Nashorn since 8u25.
> Let's move on to brighter things. Here's some new features and improvements in 8u40:
> * Optimistic typing. It actually complements static type inference: what types can't be statically inferred will be speculated upon, from more optimistic (it's an int!) to a less optimistic (it's a floating point number!) to the ultimately not optimistic at all (well, duh, it's an object after all). Nashorn has a full gradual code deoptimization framework, complete with on-stack code replacement built into it now for this purpose. Optimistic typing typically makes the warmup worse, but the warmed-up performance is significantly better, hence it's best for use with long-running applications. It's off by default, you can use the "--optimistic-types=true" command line switch to turn it on. There's a blog post that further elaborates on it: <https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the>. Marcus and I have worked on this since October 2013 and it's great that we finally shipped it to you!
> * Function.prototype.bind and Function.prototype.call now work on everything Nashorn can call, *including* POJO methods, instances of @FunctionalInterface classes etc. The tests included with the feature can give you some examples of binding and calling these non-JS callables: <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ad912b034639/test/script/basic/JDK-8051778.js>. It takes a bit of getting used to, but since POJO methods don't have the Function as their prototype, you can't just invoke "somePojoMethod.bind(...)" but must instead use Function.prototype.bind.call(somePojoMethod, this, args). Yep, you're .call()-ing Function.prototypebind, but hey, you knew JS is a functional language, didn't you? (Horrible protip: you can just type Function.bind instead of Function.prototype.bind, since the Function object is itself a function (being a JS class constructor), that is "Function instanceof Function" holds true). What about Function.prototype.apply, you might ask? Well, apply is by its nature a variable-arity invocation. It should work with vararg POJO methods, but only with them. You invoke it as "Function.apply.call(pojoMethod, ...)". In the future, we might figure out a way to use apply with non-vararg POJO methods too, but no promises on that.
> * ClassFilter interface enables you to restrict access to specified Java classes from scripts run by a Nashorn script engine; see <https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction> for details.
> Of course, these are the larger things. There is an uncounted number of smaller bugfixes and performance improvements as well. This is just a quick mail that I intended to fire off fast (first and foremost to warn you of the regression); if I forgot to mention any of the new features, I'm sure my teammates will follow up.
More information about the nashorn-dev