Hi Sundar,
Thanks for the follow up. I'm hoping for something along the lines of what you
described. The code I see seems to suggest different behavior (described
below), but it could be that I'm looking at older code (I'm using [1]) or that
I'm just looking at the wrong code.
Let's assume we'll use the same URLReader for each call to engine.eval. The
call to engine.eval will then call makeSource:
@Override
public Object eval(final Reader reader, final ScriptContext ctxt) throws
ScriptException {
return evalImpl(makeSource(reader, ctxt), ctxt);
}
This in turn creates a new Source - at least in the version I'm looking at:
private static Source makeSource(final Reader reader, final ScriptContext
ctxt) throws ScriptException {
try {
if (reader instanceof URLReader) {
final URL url = ((URLReader)reader).getURL();
final Charset cs = ((URLReader)reader).getCharset();
return new Source(url.toString(), url, cs);
}
return new Source(getScriptName(ctxt), Source.readFully(reader));
} catch (final IOException e) {
throw new ScriptException(e);
}
}
Since we created a new object for the Source, the reference check in
Source.equals will return false, and we'll fall back to doing a full array
comparison:
@Override
public boolean equals(final Object obj) {
if (this == obj) {
return true;
}
if (!(obj instanceof Source)) {
return false;
}
final Source src = (Source)obj;
// Only compare content as a last resort measure
return length == src.length && Objects.equals(url, src.url) &&
Objects.equals(name, src.name) && Arrays.equals(content, src.content);
}
Also, by virtue of calling Source(url.toString(), url, cs) we'll end up
re-reading the entire source each time we call eval:
public Source(final String name, final URL url, final Charset cs) throws
IOException {
this(name, baseURL(url, null), readFully(url, cs), url);
}
What do you think? Am I looking in the wrong place, out-of-date
code, or is my understanding flawed?
Thanks again to both you and Hannes for your patience and help.
[1]: http://hg.openjdk.java.net/jdk8u/jdk8u
Best,
Chris
________________________________________
From: nashorn-dev [[email protected]] on behalf of A.
Sundararajan [[email protected]]
Sent: Thursday, March 19, 2015 06:32
To: [email protected]
Subject: Re: 8u20 with multi-threaded class cache
Hi Chris,
If you use Nashorn's URLReader (
http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html
- 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,
-Sundar
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 [[email protected]]
> Sent: Tuesday, March 17, 2015 10:38
> To: Chris Pettitt; [email protected]; 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
