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

[Vladimir Kozlov]

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
>