I've filed a bug for this: https://bugs.openjdk.java.net/browse/JDK-8151981
For the Nashorn report, the only thing we know is that it involves pretty large scripts that are being re-evaluated in new ScriptEngines, with 8 engines at a time. So it seems quite possible that some implementation detail is stressed beyond the point where it performs efficiently. Hannes 2016-03-16 11:44 GMT+01:00 Duncan MacGregor <duncan.macgre...@gmail.com>: > I haven't seen this, but setCallSiteTargetNormal does have to get the > compiler lock, so contention can definitely cause problems. Is there a > chance you're repeatedly invalidating and setting targets? Or generating > lots of new mutable call sites? > > The other possibility is that the data structures that store the target > information aren't scaling, but j have seen a big problem there before, and > Magik on Java apps tend to be large, so I'd expect to have hit any problems > by now. > > Duncan. > > On 16 Mar 2016, at 10:28, Hannes Wallnöfer <hann...@gmail.com> wrote: > > Hi Jochen, > > we recently had a report on nashorn-dev that could be related. A user is > re-evaluating the same or similar code again and seeing more than 20x > slowdown compared to the fist evaluation. > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006024.html > > The thing is that he is using fresh ScriptEngines for the second > evaluation, so the Nashorn engines should not share anything. As with your > case, Jvisualvm shows that 80% of time is spent in > java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(). > > Hannes > > > 2016-03-15 10:28 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: > >> Hi, >> >> >> One of our users has a web application using Groovy with indy activated >> and describes the following problem: >> >> At random intervals and a random times our web servers will go from >>> serving responses in the 300 ms range to taking 30 seconds or more. >>> Sometimes the servers will recover, sometimes they require a restart of the >>> webserver (spring boot/tomcat). When the applications slow down we always >>> see the tomcat thread pool hit the maximum size. Every single thread in the >>> thread pool is in the RUNNABLE state but appears to be making no progress. >>> Successive thread dumps show that the stacks are changing, but VERY slowly. >>> The top of the stack is always this method: >>> >>> at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native >>> Method). >>> >>> The other common condition is that whatever application code is on the >>> stack is always dynamically compiled. Code that is @CompileStatic is NEVER >>> on the stack when we see these slowdowns. >>> >>> The thread dumps showed that the application code is never waiting on >>> locks, socket reads, db connections, etc. >>> >> >> Mabye worth mentioning, that with @CompileStatic annotated code is not >> using invokedynamic.... >> >> Anyway... I am wondering if anyone has had something like this before. My >> first reaction to this description would be a bug in the JVM... or a >> performance bottleneck in the JVM.... but to spend literally seconds in >> native code is pretty bad in any case. On the other hand I am not having >> this web application here to experiment with. The only part I did hear is, >> that removing the indy version of Groovy seems to fix the problem. So it >> must be either our use of indy, or indy itself having a problem here. But >> asides from this conclusion I am quite at a loss. >> >> Question 1: Did anyone have a similar problem before? >> Question 2: Maybe more to the JVM engineers, is it even possible for the >> indy part to suddenly tak seconds on compilation - or especially the >> mentioned native method? >> >> bye Jochen >> >> -- >> You received this message because you are subscribed to the Google Groups >> "JVM Languages" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jvm-languages+unsubscr...@googlegroups.com. >> To post to this group, send email to jvm-languages@googlegroups.com. >> Visit this group at https://groups.google.com/group/jvm-languages. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jvm-languages+unsubscr...@googlegroups.com. > To post to this group, send email to jvm-languages@googlegroups.com. > Visit this group at https://groups.google.com/group/jvm-languages. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jvm-languages+unsubscr...@googlegroups.com. > To post to this group, send email to jvm-languages@googlegroups.com. > Visit this group at https://groups.google.com/group/jvm-languages. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To unsubscribe from this group and stop receiving emails from it, send an email to jvm-languages+unsubscr...@googlegroups.com. To post to this group, send email to jvm-languages@googlegroups.com. Visit this group at https://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/d/optout.
