On 12/18/2011 07: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
If you don't have a mechanism like this one, you will end up by
compiling the world :)
and full the code cache so you will not able to compile newly loaded code
which is often more important than compiling method used only sometimes.
Rémi
On Sun, Dec 18, 2011 at 3:01 AM, Kirk<[email protected]> 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<[email protected]> 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<[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
