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

[Kirk Pepperdine]

On 2013-01-23, at 1:14 AM, Vitaly Davidovich <vitalyd at gmail.com> 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.

Regards,
Kirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130123/41076097/attachment.html