You say it so much better than I ever could! Kirk
On Dec 18, 2011, at 7:03 PM, Charles Oliver Nutter wrote: > 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. > -- 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.
