Threadsafety of Nashorn ScriptEngines

[Benjamin Sieffert]

What we are looking to do and basically are doing in Rhino right now (we
are not really using the javax.script api anymore for Rhino, but that is
beside the point I think), is generating a CompiledScript object and then
calling eval on it with a different Bindings object about very very often
(about 50k times per minute), in parallel. The names of the bindings
supplied by the Bindings object can of course never differ, as their usage
is hardcoded into the script. What is happening with Nashorn then is
basically what you expect from something that is not threadsafe, the
bindings get all messed up in one another.
A simple test that we have done with both Rhino (succeeding) and Nashorn
(failing) is spawning a number of threads (50 should be enough to reproduce
it) calling eval on a CompiledScript generated from the following code:

i = 0
i += 1
shortly_later = new Date()/1000 + Math.random // 0..1 sec later
while( (new Date()/1000) < shortly_later) {
  Math.random() //prevent optimizations
}
i += 1

Obviously we check whether the result is 2 for each evaluation and reliably
get a huge number of wrong ones, the values ranging from 1 to 6 mostly,
with a noticable concentration at 3. Of course the exact results will
always vary.

Now in this case there is not even a Bindings supplied, though you can
produce the same erratic behaviour by cutting the declaration of i in the
first line and passing in a Bindings with "i" => 0. It is also possible to
not look at the result directly, but instead fetch the engine's binding for
"i" after execution
(script.getEngine().getBindings(ScriptContext.ENGINE_SCOPE).get("i")): The
expected value will still be fail to be matched in many cases.

Hope this is of use to you
Best regards



2013/4/18 Jim Laskey (Oracle) <james.laskey at oracle.com>

> It is not currently thread safe, but we have several requirements to make
> it so.  Would you describe how you are using threading in Rhino now and
> would you supply a test case?
>
> Cheers,
>
> -- Jim
>
>
>
>
> On 2013-04-18, at 6:58 AM, Benjamin Sieffert <benjamin.sieffert at metrigo.de>
> wrote:
>
> > Hello everyone,
> >
> > we are experimentally implementing Nashorn in a little project that is
> > currently using Rhino for javascript purposes right now. While it is
> > generally working well, it does not appear to be threadsafe in regards to
> > scripts generated by / running on the same ScriptEngine object. Now while
> > NashornScriptEngineFactory does not claim otherwise
> > (getParameter("THREADING") is null), we did not find any definitive
> > information on what the ultimate goal of Nashorn is in this regard.
> > Could you enlighten us?
> >
> > Best regards
> >
> > --
> > Benjamin Sieffert
> > metrigo GmbH
> > Sternstr. 106
> > 20357 Hamburg
> >
> > Geschäftsführer: Christian Müller, Tobias Schlottke, Philipp Westermeyer
> > Die Gesellschaft ist eingetragen beim Registergericht Hamburg
> > Nr. HRB 120447.
>
>


-- 
Benjamin Sieffert
metrigo GmbH
Sternstr. 106
20357 Hamburg

Geschäftsführer: Christian Müller, Tobias Schlottke, Philipp Westermeyer
Die Gesellschaft ist eingetragen beim Registergericht Hamburg
Nr. HRB 120447.