RFR: 8170785: Excessive allocation in ParseUtil.encodePath

[Roger Riggs]

Hi Claes,

So Windows didn't suffer from having the '\' separator.

ParseUtil:

firstEncodeIndex:121:
   'a' - 'z' seems more frequent than '/' or '.'; does it improve the 
stats to move that range to the beginning of the if.
   (yes the compiler can re-order).

line 125:
     Since 127 is known to need encoding it could be >= 0x007f

line  136: I suppose the arraycopy intrinsic already optimizes length == 0;

Line 134:  I question the math on  * 2 + 16 -index;  (But this is 
pre-existing code)
    if there were lots of characters that needed encoding it might be 
possible to overflow the array since 1 char is replaced by at least 3 
and up to 9.
    16 seems like a questionable fudge factor; but perhaps it has not 
been a problem in practice.

$.02, Roger



On 1/3/2017 9:46 AM, Claes Redestad wrote:
> Hi,
>
> some users reports high allocation rates in ParseUtil.encodePath,
> regardless of whether paths actually need to be encoded or not.
> Since this is a commonly used utility it makes sense.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170785
>
> This patch provides a semantically neutral fast-path for cases when
> the path does not need to be encoded (up to 5x speedup), reduces
> allocation when the string has a prefix that does not need to be
> encoded (1-2x speedup) and no regression when using a separator
> that's not '/' or the first char needs encoding.
>
> Interpreted performance is not affected much either: small positive
> when no encoding is needed, neutral or negligible regression
> otherwise.
>
> Thanks!
>
> /Claes