Nashorn caching of processed scripts?

David P. Caldwell david at
Thu May 1 11:53:13 UTC 2014

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

On Thu, May 1, 2014 at 7:35 AM, David P. Caldwell
<david at> 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

More information about the nashorn-dev mailing list