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

Ulf Zibis Ulf.Zibis at CoSoCo.de
Sat Jan 26 03:08:50 UTC 2013

Am 23.01.2013 08:56, schrieb Kirk Pepperdine:

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

This is why I considered to include the surrounding code/API in the optimization thoughts as well for possible better performance for small strings, even on C2 or for less than 10.000 invocations.

-Ulf

More information about the core-libs-dev mailing list