Nashorn caching of processed scripts?

[Attila Szegedi]

Hi David,

no, there's no such caching in the currently released version. Compilation happens on the thread that invokes the relevant javax.script API (e.g. ScriptEngine.eval or Compilable.compile), so there's no asynchrony involved either. The behavior you describe is indeed baffling, but I don't have an explanation for it within the Nashorn compilation pipeline.

Attila.

On Apr 30, 2014, at 4:04 PM, David P. Caldwell <david at code.davidpcaldwell.com> wrote:

> 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/