This architecture is actually still problematic for me.
My specific problem is that I define a different stdout and stderr per
request. Because these are stored in the ScriptEnvironment in the
Context, it means I also need a unique Context per request.
Why not make it possible to use Context with multiple ScriptEnvironment
instances? It seems that all that would be necessary is to add a setEnv
method to the class.
On 03/12/2014 06:30 PM, A. Sundararajan wrote:
Actually, the plan is to get to 8u20 - which is an update release
after jdk8 GA.
Script engine is associated with a single nashorn Context instance.
One nashorn Context instance may be associated with multiple nashorn
Global instances. The class sharing as of today is per global instance
- after Hannes' change, it'll be per Context instance (and so sharing
across all globals associated with a nashorn Context instance).
ScriptEnvironment._class_cache_size is set from --class-cache-size
option. Currently it is interpreted as per-global cache size. After
Hannes' change, it is per-Context class cache size.
-Sundar
On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote:
I did see that change come through, but I thought it was a JDK9
feature... great to know it is for JDK8!
I'll note that I'm not using ScriptEngine, but instead working on the
Scripturian implementation. How will ScriptEngine make sure to reuse
the cache?
Would it be possible to also allow a shared ClassCache instance for
all globals? How about a ScriptEnvironment._class_cache_size boolean
option to enable this?
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.
