8u20 with multi-threaded class cache

A. Sundararajan sundararajan.athijegannathan at oracle.com
Thu Mar 19 13:32:09 UTC 2015

Hi Chris,

If you use Nashorn's URLReader ( 
- a Reader wrapping a script URL object), then nashorn's Source would be 
cached against that URL could be re-used (and the compiled Class object 
as well via findCachedClass).

     engine.eval(new URLReader(myScriptURL));

Also, any script loaded via "load(url)" built-in could also be 
compiled/cached and re-used (against that URL + last modified since of 
the same).

Hope this helps,

On Thursday 19 March 2015 04:00 AM, Chris Pettitt wrote:
> Hannes,
> Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.
> For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.
> Thanks,
> Chris
> ________________________________________
> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
> Sent: Tuesday, March 17, 2015 10:38
> To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
> Subject: Re: 8u20 with multi-threaded class cache
> Hi Chris, Kunal,
> Answers are inlined below.
> Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
>> Hi folks,
>> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?
> This is correct as far as Nashorn is concerned. In the original JDK8
> release, using a ScriptEngine with multiple bindings/globals will
> compile each script from scratch. We introduced the class caching in
> 8u20 as our best effort to fit code reuse on the existing ScriptEngine
> API. The only caveat I can think of is that code may run slower with
> multiple bindings because of callsite polymorphism. Also bear in mind
> that this is a relatively new feature, but there seemed to be no problem
> using it with your dust scripts (see example below).
>> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?
> You can actually use this with Invocable.invokeMethod(), passing the
> binding as first argument ("thiz" parameter). I've rewritten the
> threaded class cache example from the blog post to do this with your
> dust benchmark and it seems to work fine:
> https://gist.github.com/hns/8f52a620ce36daa3d0ca
> I just edited the bench.js file to remove the benchmark loop at the
> bottom, otherwise this will run with the script files you sent me. Feel
> free to use this as a starting point for your own testing.
> It could also work with the other Invocable method taking a "thiz"
> parameter, getInterface(Object, Class), but I haven't tested this.
>> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.
> I'm not sure I understand this question. What I use in my example is
> jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
> source URL in error messages.  I believe Nashorn will still load the
> content of the URL to make sure scripts are actually identical.
> I hope this helps. Let me know if you have further questions.
> Regards,
> Hannes
>> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>> Thanks,
>> Chris

More information about the nashorn-dev mailing list