Nashorn caching of processed scripts?
David P. Caldwell
david at code.davidpcaldwell.com
Wed Apr 30 14:04:38 UTC 2014
Does Nashorn do some kind of background incremental compilation and
caching of compiled scripts somewhere in the local file system? Is it
possible to disable it?
I'm porting a very complex Rhino-based system -- complex in terms of
scope and 'this' management in particular -- to Nashorn and I'm
running into behavior consistent with that, so I'm wondering (and I'm
wondering whether I can disable it temporarily or force it to run
synchronously or in advance).
The reason I ask is that after I make a code change I tend to get an
initial error (A) until I run the tests 1-3 times, and then that error
disappears and I get a different error (B). The fact that error A
seems to be triggered by changing one of the scripts in the system --
I haven't figured out which one, or ones -- leads me toward the theory
that there is a background process that leaves a mark on disk at work.
I don't yet know what is really going on with Error A is because it's
harder to reproduce than Error B -- after 1-3 runs I can reproduce
Error B so I will surely figure that one out first.
Error B, for what it's worth, seems to have to do with a reference to
an argument being lost inside one of the scopes of an object. So a
named argument essentially acquires a different value:
var Constructor = function(parameter) {
this.doIt = function() {
parameter.doSomething();
}
}
In that usage, the parameter reference is somehow being lost (and ends
up referring to a value from a different call to the same
constructor). I was able to fix one occurrence of this by replacing
the construct above with:
var Constructor = function(parameter) {
this.parameter = parameter;
this.doIt = function() {
this.parameter.doSomething();
}
}
If I nail down why this is happening at some point I'll report it, but
right now there's so much surrounding code that I can't easily provide
a reproduction case or nail down the root cause. And it may not even
qualify as a "bug" because (a) it is possible that somewhere some
threading rule is being violated in my code, and (b) I am already
using a non-public Nashorn API
(jdk.nashorn.internal.runtime.Context.evaluateSource(Source,ScriptObject,ScriptObject))
to replicate things the Rhino-based system was able to do with its
custom embedding.
I sort of doubt the threading explanation because as this is a test
suite it is mostly single-threaded, but it's possible I'm missing
something.
So anyway, back to my question -- is there caching of some kind of
code transformation, and if there is, can I disable it so I can narrow
down on error A? Or force it to happen synchronously so that I can
work around error A?
-- David P Caldwell
http://www.davidpcaldwell.com/
More information about the nashorn-dev
mailing list