Correct me if I'm wrong but ou seem to be describing de optimization. Counter decay, as I understand it, wacks the value of the counters by 1/2 every 30 seconds.. checking every 1/2 second. So luke warm methods that never hit the compile threshold before the 30 second time limit will never be compiled. Flashing the system circumvents this by artificially forcing the issue... which, I would guess, could result in a less than optimal compile. I would argue in long running processes it's better to let lukewarm methods compile and in fact, this is my preferred approach when I see this happening. I've got a silly benchmark in my performance tuning course that exercises it. You can see the difference with PrintCompilation turned on as luke warm methods show up under load and they won't when the system is lightly loaded.
Regards, Kirk On Dec 17, 2011, at 10:34 PM, Charles Oliver Nutter wrote: > 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. > -- 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.
