That's great to hear, Tal.
The gates for JDK8 are definitely closed, but u20 is scheduled for q3
2014, so you won't have to wait too long. I also think there will be
preview releases available on jdk8.java.net for quite some time before
release.
Thanks for testing and feedback!
Hannes
Am 2014-03-12 13:41, schrieb Tal Liron:
Great work, Hannes!
With the jdk9 version, it seems caching improves performance by two
orders of magnitude. :) And a simple benchmark shows the same code
working twice as fast in Nashorn as compared to Rhino.
This leaves me in a strange position in terms of what to tell my
users. Should I recommend waiting until 8u20 is out? (And when is that
going to be?) Or would it make sense for me to provide my own
custom-built nashorn.jar?
I'm worried, of course, about a custom-built jar, because it would be
a snapshot of a development version.
I really, really wish this feature could make it to the official
OpenJDK 8 release. Any strings you guys can pull to make it happen?
On 03/12/2014 08:06 PM, Hannes Wallnoefer wrote:
Am 2014-03-12 12:44, schrieb Tal Liron:
Hannes, I would like to test this.
It doesn't seem to be on the main Nashorn repository:
http://hg.openjdk.java.net/nashorn/jdk8/nashorn
Is there a separate repository I should be using?
You can get it here:
http://hg.openjdk.java.net/jdk9/dev/nashorn
In case you have problems with building I can send you a nashorn.jar
via private mail. Just let me know.
Hannes
On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote:
Hi Tal,
I'm right now pushing a change for JDK-8021350 that allows sharing
script classes between global scopes. Currently, script classes are
bound to the global object in various ways, so the change is not
trivial, and it's not possible to share compiled scripts between
global scopes with the nashorn.jar in current JDK8 builds. The
script sharing feature is planned for the 8u20 release.
The class sharing will be per script engine, meaning that if you
use multiple scopes with one script engine classes will be reused,
when you use multiple script engines scripts will be recompiled for
each engine.
I'd be interested to know whether this would work for you. If you'd
like to test the class sharing feature I can help you getting started.
Hannes
Am 2014-03-12 10:27, schrieb Tal Liron:
In Nashorn, the ClassCache is set per Global instance.
This is fine if your application has only one global instance.
However, my application design involves creating many Global
instances. (Actually, I create and destroy them on the fly per
user request in an HTTP server scenario.) The problem is that all
code has to constantly be recompiled, and the cache is essentially
never used. Since recompilation is so very expensive in Nashorn,
this results in awful performance.
How can I implement a shared ClassCache? I can't extend and modify
Global behavior, because it's a final class.
I've tried to cache ScriptFunction instances myself, but I get
exceptions when I try to run them with a different Global instance
than the one that created them.
