Hi Benjamin and Rémi,
> 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. > > Nashorn has and always has had the feature to turn callsites into megamorphic mode after 8 or 16 (depending on version and options) relink events. In the case that currently popped up on nashorn-dev, the user reports the problem occurs with freshly created ScriptEngines, meaning no code will be reused from the old ScriptEngines. Now even if we assume some code is reused between engines and needs to be relinked, it's very hard to explain a > 20x performance drop between first and second evaluation. After all, callsites have to be linked the first time around as well. Hannes -- 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.
