A-ha, now I understand. So if you have an expensive method that's not called frequently enough to beat the decay, it never JITs. Yeah, I wonder why that's there. Seems like the JIT should eventually compile everything that's getting used enough to reach call thresholds.
- Charlie On Sun, Dec 18, 2011 at 3:01 AM, Kirk <kirk.pepperd...@gmail.com> wrote: > 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. > -- 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.
