Nashorn caching of processed scripts?

[Jim Laskey (Oracle)]

Thank you.

On Sep 2, 2014, at 9:16 AM, David P. Caldwell <david at code.davidpcaldwell.com> wrote:

> Whatever the original problem was here, it appears to have been fixed in
> the version of Nashorn bundled with 1.8.0_20.
> 
> My test cases now consistently pass under 1.8.0_20 and consistently fail
> under 1.8.0. I haven't bisected beyond that.
> 
> My understanding is that the script caching stuff was recently changed
> (reading https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn)
> and integrated into 1.8.0_20. Either this reorganization fixed a bug or
> made the code being invoked work more consistently like my code expected it
> to work.
> 
> Just keeping you up to date in case this rears its head in the future with
> someone using an older version.
> 
> -- David.
> 
> 
> On Thu, May 1, 2014 at 7:53 AM, David P. Caldwell <
> david at code.davidpcaldwell.com> wrote:
> 
>> A couple of other hints/guesses:
>> 
>> My guess is Nashorn caches the compiled version of a given script by
>> examining the Source used to create it.
>> 
>> 1. It appears this bug manifests when the same script is loaded into
>> several places, and it appears that if the script loads "wrong" it
>> loads wrong everywhere. In other words, if the script is loaded into
>> one scope and exhibits this behavior, it will exhibit it again within
>> a single execution if it is loaded into another scope.
>> 2. The stack trace seems to lead through
>> LinkerServicesImpl.getGuardedInvocation() and DynamicLinker.relink().
>> 
>> -- David P. Caldwell
>> http://www.davidpcaldwell.com/
>> 
>> On Thu, May 1, 2014 at 7:35 AM, David P. Caldwell
>> <david at code.davidpcaldwell.com> wrote:
>>> For what it's worth, I've learned a bit more about my problem with
>> scopes.
>>> 
>>> I have a set of unit tests that exercise my system, and as such, they
>>> are very scope-intensive, because they use scopes as the mechanism for
>>> mocking and dependency injection when running the unit tests.
>>> 
>>> They always pass under Rhino.
>>> 
>>> Under Nashorn, these tests intermittently failed because of various
>>> mistakes having to do with scoping. In my current tip I believe I've
>>> worked around all the unit test failures that are "common" but it's
>>> too early to be sure.
>>> 
>>> So, I have a lot of constructs like this:
>>> 
>>> var someFunction = function() {
>>>  // omitted
>>> }
>>> 
>>> this.somePublicFunction() {
>>>  someFunction();
>>>  // ...
>>> }
>>> 
>>> What I can tell you is:
>>> 
>>> * The unit tests are continually creating and using scopes to mock the
>>> execution context, and they re-enter Nashorn via the non-public
>>> evaluateSource(Source,ScriptContext,ScriptContext) and then invoking
>>> functions like somePublicFunction() above.
>>> * Sometimes, in a non-deterministic way, in scripts like the above,
>>> "someFunction" evaluates to undefined inside somePublicFunction.
>>> * I can fix the problem in various ways, including making someFunction
>>> a property of this or moving it inside somePublicFunction.
>>> 
>>> Given that it's non-deterministic, my suspicion is some kind of race
>>> condition or concurrency problem.
>>> 
>>> I mentioned earlier that I thought the problem would occur when I
>>> modified code and then stop occurring. It's possible I imagined this
>>> pattern, or it's possible that CPU temperature and throttling is what
>>> caused it (repeatedly running a large test suite may have affected the
>>> concurrency stuff).
>>> 
>>> If I thought about it carefully, I could provide an executable test
>>> case based on a previous revision of the code. The good news is, it
>>> would just involve checking out some public code at a given revision
>>> and running a single command to start the tests. Three pieces of bad
>>> news: 1. it's non-deterministic, 2. it's obviously big and tangled so
>>> you'd have to figure out how to catch the problem, and 3. I'm using a
>>> non-public API (which I am calling from script, no less), so I can't
>>> guarantee that's not related to the problem.
>>> 
>>> But with those three caveats, if you're interested, let me know and
>>> I'll assemble something.
>>> 
>>> -- David P. Caldwell
>>> http://www.davidpcaldwell.com/
>>