Hi Benjamin, ----- Mail original -----
> De: "Benjamin Sieffert" <benjamin.sieff...@metrigo.de> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Cc: "Nick Houghton" <nhoug...@gmail.com>, jvm-langua...@googlegroups.com > Envoyé: Mercredi 16 Mars 2016 13:59:58 > Objet: Re: [jvm-l] slow downs in invokedynamic native code > Hi, > I did run into this issue with Nashorn as well. That was back in 2013, but a > certain Nick Houghton (cc, who will be glad to here there’s finally a bug > filed) contacted me about that in Dec'15, asking whether I had made any > progress, because he had discovered the same issue. > Here’s my original thread: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-September/005489.html > Maybe Jochen or Remi will still remember. I don't remember ... i'm like a goldfish ... but the internet saves me (thanks for the link) > Anyways, I think we did solve this issue by eliminating a pattern where we > would globally define objects in our script environment via calls to > NashornScriptEngine.put. I suspect that overriding the same global variable > repeatedly and hence, I suppose, invalidating corresponding call sites, > might’ve triggered the pathologic behaviour. > Just wanted to let you know, in case it help narrowing down the issue / > understanding the impact. It's a perfect example of a Nashorn bug (not a VM bug), any global (maybe constant?) should have a counter counting the number of time the global is changed, and if the counter is above a threshold, the runtime should stop trying to see it as constant. Perhaps we should have a section about deopt storm in the documentation saying that the code of the runtime should always have a backup strategy in case the method handle chain is constant enough for the JIT but not constant if you take a look to the whole program. > Kind Regards, > Benjamin regards, Rémi > On 16 March 2016 at 12:41, Remi Forax < fo...@univ-mlv.fr > wrote: > > The symptoms are really like a deoptimization storm, > > > setCallSiteTargetNormal goes to a safepoint (which is worst that only > > having > > the compiler/JIT lock because all threads are stopped), > > > when either a code calls setTarget or a SwithPoint is invalidated. > > > You have a deopt storm when the JIT compiles a code that contains a > > callsite > > that is always invalid, so the VM enters in loop like this, > > > JIT compile a blob > > > execute the blob > > > deopt > > > jump back in the interpreter > > > rinse and repeat > > > The root cause is a bug in the invalidation logic of the language runtime > > (not the VM) but it's hard to spot without a reproducible test case because > > > when the JIT compiles a blob of codes there are several callsites inside > > that > > blob and usually only one is the faulty one. > > > We already have discussed about that point several times, > > > John is a proponent of marking the callsite has should never be optimized > > again, > > > which at least stop the storm issue but it sweeps the real cause of the bug > > under carpet, > > > I would prefer, consider these kind of bugs as a language runtime bugs that > > should be investigated by the runtime developers. > > > Perhaps a middle ground is to mark the callsite as not compilable anymore > > *and* emit a warning (like when the code cache is full) to not hide the > > root > > cause of the bug. > > > Rémi > > > > De: "Hannes Wallnöfer" < hann...@gmail.com > > > > > > > À: jvm-langua...@googlegroups.com > > > > > > Envoyé: Mercredi 16 Mars 2016 11:52:42 > > > > > > Objet: Re: [jvm-l] slow downs in invokedynamic native code > > > > > > 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-langua...@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-langua...@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-langua...@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-langua...@googlegroups.com . > > > > > > Visit this group at https://groups.google.com/group/jvm-languages . > > > > > > For more options, visit https://groups.google.com/d/optout . > > > > > _______________________________________________ > > > mlvm-dev mailing list > > > mlvm-dev@openjdk.java.net > > > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -- > Benjamin Sieffert > metrigo GmbH | A Zalando Company > Lagerstraße 36 > 20357 Hamburg > Geschäftsführer: Tobias Schlottke, Philipp Erler > Die Gesellschaft ist eingetragen beim Registergericht Hamburg HRB 120447 > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
