In Rhino, you would just inject the classes into a reusable ScriptableObject that provided a context that could be re-used across many executions. We would create a ScriptableObject, call initStandardObjects() on it, call putProperty to add class references and defineFunctionProperties to add new base functions, and then keep that resulting ScriptableObject and re-use it over and over again as the execution context.
Is there nothing analogous to this with Nashorn? ________________________________________ From: nashorn-dev <[email protected]> on behalf of Tal Liron <[email protected]> Sent: Wednesday, March 12, 2014 7:03 AM To: [email protected] Subject: Re: The class cache Ugh, you're right ... Well, I do kinda have a hacky solution I could put in: implement my own PrintWriter wrapper that uses a thread-local. I think it would be better if stdout and stderr were in Global. On 03/12/2014 07:00 PM, Rick Bullotta wrote: > Tal, I don't think that would work in a multi-threaded environment, would it? > Calling setEnv on the single instance of the class would be problematic if > it was executing on multiple threads in multiple contexts, I'd think... > ________________________________________ > From: nashorn-dev <[email protected]> on behalf of Tal > Liron <[email protected]> > Sent: Wednesday, March 12, 2014 6:57 AM > To: [email protected] > Subject: Re: The class cache > > 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.
