Explosions in calls to MutableCallSite.setTarget

[A. Sundararajan]

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