Rémi, well I got into more detail on how we use nashorn on their mailing list, because I supposed this wouldn't be so much the issue here. Anyway, you're bringing up a point that they did not, so here's specifically what we do:
Each of our ~200 javascripts is set up to return a "scriptrunner" object. This object is 100% javascript. For each javascript, we create a (Nashorn)ScriptEngine, because we need a few bindings to be different for each script. Before passing the javascript to the engine, we .put() the relevant bindings into it. Then we retrieve our javascript-side "scriptrunner" object by calling .compile(javascript).eval() on the engine. (So we get a compiled script at this point, but that is not the object we store and use.) Now the "scriptrunner" is set up to fit our needs. We work with it by calling engine.invokeMethod(scriptrunner, "methodname", arguments) (not possible with every ScriptEngine, but NashornScriptEngine supplies this functionality). So we're effectively calling eval not at all, at least not permanently. Looking at the nashorn-stacktraces, though, all their calls are jdk.nashorn.internal.scripts.Script$\^eval\_._L[line number](<eval>:[another line number]) I think it's just how they work internally. And to be honest, I'm not really sure if in our case the lone call to compile once is necessary, as a whole lot of optimization seems to only start happening when we start calling the scriptrunner and not when we create it. Regards, Benjamin
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
