Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86

Kirk Pepperdine kirk at
Wed Jan 23 07:56:18 UTC 2013

On 2013-01-23, at 1:14 AM, Vitaly Davidovich <vitalyd at> wrote:

> Personally, optimizing for interpreter (or even C1) doesn't seem worth it.  If something's truly hot and best perf is desired then use C2 or tiered.  If the method isn't hot enough to trigger the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance.  Maybe this is heresy though :).
Maybe, maybe not.. what I can say is this is a case of an optimization that doesn't scale down. In cases where scale down was needed I have recommended to customers that they "flash" their system just to push the counter beyond the compile threshold. In those cases naively compiled code was still a lot better than interrupting byte code. I've also turned off decay in a number of applications where loads weren't quite enough to beat the decay behaviour. Yeah I know this is at the risk of filling code cache but code cache occupancy is something that I regularly recommend people monitor for (check my VisualVM memory pool plug-in). In fact, I just tuned an app where I used -Xcomp to estimate how big the code cache needed to be to avoid filling it. Production settings had decay turned off. So, I can't say your wrong and I generally don't like fiddling with these setting but I will if I have to and I've had to in a number of instances where ensuring a compile beat leaving it alone.


More information about the core-libs-dev mailing list