Hi,

Thanks for writing to us. Yes - Nashorn jdk7 is more of what we'd say "experimental".

There have been changes in jsr292/jdk as well as in nashorn with the latest jdk8 codebase. Please use nashorn in jdk8 pre-release snapshots.

If the issue you are seeing is reproduced with jdk8, please file a bug or send us the details (in this list) and we'll file a bug.

Thanks
-Sundar

On Friday 06 September 2013 07:14 PM, Benjamin Sieffert wrote:
Hi everyone,

we're still eager users of nashorn around here and while doing some
profiling stumpled upon a kind of weird behaviour, where there are periods
almost our complete CPU is consumed by calls to setTarget / setTargetNormal
on java.lang.invoke.Callsite.

What we do in our code is to initialize a few hundred script engines and
let each run a javascript that returns a js-object once. Then we store this
returned js-object and call a certain method on it in massive scale. There
is some amount of accessing java objects this javascript.

As we initialize the script engines, there is of course a noticable surge
on cpu load, as the javascript gets compiled and optimized. But this dies
down within a few minutes and we see a very good performance, until
suddenly our threads start to get very very busy with the already mentioned
calls so setTarget(). This will die down after a while, too, but happen
again after seemingly random periods.

Looking at the exact stack trace, it's:
at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
Method)
java.lang.invoke.CallSite.setTargetNormal(CallSite.java:270)
java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154)

I have to admit that we are still using the jdk7-backport, though, which
has not been updated since July. Possibly this is a problem already fixed
in the jdk8 branch. If so, keep up the good work! :) If not, I'd gladly
take any input on what might cause this problem and what we might do to
counteract it.

Best regards
Benjamin

Reply via email to