RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1
Aleksey Shipilev
aleksey.shipilev at oracle.com
Thu Dec 17 16:47:01 UTC 2015
On 12/17/2015 04:54 PM, Ulf Zibis wrote:
> Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev:
>> On 12/17/2015 02:34 AM, Ulf wrote:
>>> I'm wondering why moving the increment operation to an extra line wound
>>> enhance performance.
>> Because C1 is very straightforward, and code movement like that is a
>> poor man's instruction scheduling, that pads out the data dependency
>> between index update and indexed access.
>
> Thanks.
> Shouldn't this simple optimization be addressed to javac?
> Otherwise programmers always risk some performance when using the
> post-increment idiom, which IMHO is good code style.
No, it should not be addressed in javac, as good optimizing compiler
would handle this without involving bytecode scheduling in the Java
compiler.
With C1, it is always the "low-cost" branch of cost-benefit game -- if
you can spend a few hours polishing the code to make it perform better
with C1, then you should do it. But, wasting man-years of effort to
please C1 is not almost wise resource investment. This is why I am
resistant to any sort of bikeshedding w.r.t. these particular changes --
we did them, they improved C1, let's move on.
Thanks,
-Aleksey
More information about the core-libs-dev
mailing list