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.
