Calls to native methods setCallSiteTargetNormal and defineAnonymousClass taking very long

[Benjamin Sieffert]

No, I think you misunderstand me. We are keeping the javascript(!) object
we got from the compiled script and with it, I assume, we keep the compiled
script / its optimization. We are in no way re-initializing scripts /
script engines with every call.
The problem is that we don't really have another way of passing our
case-by-case variable into the javascript than storing the scriptrunner and
going the invokeMethod-route, since nashorn is not threadsafe in a way that
allows calling of CompiledScript.eval(Bindings) in parallel: The passed
bindings will conflict with each other. The only bindings we can .put()
into the engine are the ones supplying "shared" data that does only get
read, not modified from inside the script. So for further concurrency we
are stuck with building our own inside the javascript, by passing the
relevant variables between functions and not exposing them globally.

I really hope this explanation is understandable. 99,9% of our calls into
js are this line:
engine.invokeMethod(runner, "run", api);
The "api" object is different every time, the engine and the runner are
initialized once and don't get changed.

2013/9/20 Jochen Theodorou <blackdrag at gmx.org>

> Am 20.09.2013 12:56, schrieb Benjamin Sieffert:
> [...]
> > 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.)
>
> can't you reuse the compiled scripts? Depending no how that is
> implemented it could improve the situation
>
> > 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.
>
> if compile produces a new... let's say class, each time, then you get
> all the callsites and all the helper code new too. There might be
> internal compilation and optimization ongoing after compile, but it
> sounds to me as if nothing of that is going to be reused later, since
> you through the optimized result away. And next time, you start fresh.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>



-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130920/e875d74e/attachment.html