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

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 23 00:14:54 UTC 2013

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 :).

Sent from my phone On Jan 22, 2013 6:58 PM, "Ulf Zibis" <Ulf.Zibis at cosoco.de> wrote:

Am 22.01.2013 21:20, schrieb Vladimir Kozlov:

Thank you, Ulf

I will rename method to encodeISOArray and add comment that it could be replaced by intrinsic by JVM. Thanks, that's much better. Thinking about, I would more like encodeArrayToISO or just encodeToISO88591. The same arrays were use intentionally in test to get performance of code without effect of CPU's cache/memory subsystem. I worry about, if the overhead of recalculating sp and dp + comparing ret != len + complicated calculation of len will come to effect on short strings, at least on C1 and interpreter. So why not choose the best code for all these cases? The method encodeArrayLoop() is also compiled because it is invoked > 10000 times. That is what I assumed. But I see 2 corner cases: - Programs with sparse use of ISO-8859-1 encoding will not profit of it, if the compile threshold becomes not reached. Also think about C1. - I worry, that on small strings the performance of the the intrinsic surrounding code would come to some account, even if JIT-compiled, but specially on C1 and interpreter. So would it hurt, to include those cases while tuning? -Ulf

More information about the core-libs-dev mailing list