CounterDecay is new to me...am I reading the code right when I get that it basically decays compiled code over time, eventually forcing a reprofile and recompile of steady-state code?
I know there's a SmallTalk impl onindy doing something similar...periodically, all call sites are flushed and allowed to rebuild. It's an interesting pattern, but I think you'd eventually want to decay the decay and stop doing it, eh? It looks like you can turn it off at least... -XX:-UseCounterDecay - Charlie On Sat, Dec 17, 2011 at 2:18 PM, Kirk <kirk.pepperd...@gmail.com> wrote: > Slightly off topic but... since inlining was mentioned.... One of the > problems I've encountered with low latency applications are luke warm methods > running in less busy installations. These can result in response that often > slower by a factor 5x or greater than installations that are busier. In call > cases this tracked to CounterDecay. Solution was to either flash the server > to pop the counters or simply turn off counter decay. Azul doesn't use > counter decay and I'm wondering if people have considered simply pulling it > out or turning it off by default? > > Regards, > Kirk > > On Dec 17, 2011, at 9:04 PM, Charles Oliver Nutter wrote: > >> On Sat, Dec 17, 2011 at 1:10 PM, Rémi Forax <fo...@univ-mlv.fr> wrote: >>> So there is a bug in the way the inlining budget is computed. >>> The pattern doesn't use any side methods is the fast path, >>> only method handle adapters so it should not entail the >>> inlining budget at all. >>> >>> I've only tested on small examples, so it was always fully inlined >>> but I think it worth investigating why there is a problem with >>> the inlining budget. >> >> In my case, I believe Christian determined it was an inlining issue. >> When I added this pattern into all compiled Ruby code, it bumped up >> some budget to the point that hot paths stopped inlining. I suspected >> that it might be NodeCountInlinigCutoff, which currently does not >> discount MH chains, and Christian said that was indeed possible. >> >> The other half of the bug is that when indy + MH chain does not >> inline, performance is *dismal*. I believe John's upcoming rework of >> the inlining logic is supposed to fix both issues. >> >>> Or it's not an inlining budget problem, the other problem I see >>> is that if the code is not yet JITed, it's slow, far slower than >>> a field access even a volatile one, so if the method is not hot >>> but only warm, you may have trouble. >> >> That's certainly true. I doubt it affects most code, though, since if >> it's hot enough for you to notice that it's slow, it's probably hot >> enough to JIT. >> >> - Charlie >> >> -- >> You received this message because you are subscribed to the Google Groups >> "JVM Languages" group. >> To post to this group, send email to jvm-languages@googlegroups.com. >> To unsubscribe from this group, send email to >> jvm-languages+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jvm-languages?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to jvm-languages@googlegroups.com. > To unsubscribe from this group, send email to > jvm-languages+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
