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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Jan 23 19:19:22 UTC 2013

To close this discussion before I do the push here are performance numbers for C1. Numbers are almost similar (few % worser, note that with C2 it improved) because C1 does not do loop optimizations.

size: 1 time: 25 26 size: 7 time: 33 34 size: 8 time: 34 36 size: 16 time: 45 47 size: 32 time: 66 68 size: 64 time: 117 119 size: 128 time: 203 205 size: 256 time: 374 376 size: 512 time: 718 719 size: 1024 time: 1407 1403 size: 2048 time: 2776 2775 size: 4096 time: 5519 5517

Today is the last day when I can do this push before feature freeze. And I did tons of testing with current code (latest webrev) so I am not going to change it just before the push.

Thanks, Vladimir

On 1/22/13 11:56 PM, Kirk Pepperdine wrote:

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. Regards, Kirk

More information about the core-libs-dev mailing list