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 <[email protected]>: > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/d/optout.
