The class cache

Rick Bullotta rick.bullotta at
Wed Mar 12 11:00:57 UTC 2014

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 <nashorn-dev-bounces at> on behalf of Tal Liron <tal.liron at>
Sent: Wednesday, March 12, 2014 6:57 AM
To: nashorn-dev at
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.

More information about the nashorn-dev mailing list