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

[Ulf Zibis]

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