Thank you. On Sep 2, 2014, at 9:16 AM, David P. Caldwell <[email protected]> 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 < > [email protected]> 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 >> <[email protected]> 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/ >>
