Nashorn caching of processed scripts?

[David P. Caldwell]

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