Nashorn caching of processed scripts?

[David P. Caldwell]

Thanks, Attila.

I'm still in the "bootstrapping" process with Nashorn so I haven't
gotten to the point where I can run my scripts in a visual debugger,
build and run Nashorn myself, etc. As I advance undoubtedly I'll
acquire more tools and be able to further describe problems like the
two noted above.

I've already solved Error B: a local variable declared inside an
object created by new was somehow getting shared across instances of
the object (so a generalization of the problem I ran into earlier,
where a constructor argument was being shared). Again, assigning the
local variable to the object -- to 'this' -- and then using the object
property fixed the problem. So if at some point I can narrow down why
this is happening I'll let the list know.

-- David P. Caldwell
http://www.davidpcaldwell.com/

On Wed, Apr 30, 2014 at 10:42 AM, Attila Szegedi
<attila.szegedi at oracle.com> wrote:
> 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/
>