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