RFR: 8196331: Optimize Character.digit for latin1 input

[Xueming Shen]

+1

On Jan 30, 2018, at 2:40 AM, Claes Redestad <claes.redestad at oracle.com> wrote:

The ASM is harder than usual to follow and compare since everything is
inlined aggressively, but it seems that since CharacterDataLatin1 is only
invoked for 0 <= ch < 256 (invariant established in CharacterData.of(int ch))
then the compiler is able to elide bounds check entirely when the byte[] is
also 256 elements.

Shrinking the array adds more branches and grows the compiled code size
for UUID.fromString from 751 to 1341 bytes, so it seems that even from a
footprint perspective then keeping the array at 256 elements is a win. :-)

/Claes

> On 2018-01-29 22:04, Claes Redestad wrote:
> Right, I can't really explain why, but the effect is very visible and
> reproducible in microbenchmarks. Differences in generated ASM might
> be indicating that the inlining behavior changes enough to shift the
> result around; maybe a job for @ForceInline?
> 
> I'll experiment and analyze a bit more tomorrow to see if I can find a
> good explanation for the observed difference and/or a solution that
> allows us to slim down the lookup array.
> 
> /Claes
> 
>> On 2018-01-29 20:38, Paul Sandoz wrote:
>> Smaller in only the upper bound? I would an explicit upper bounds check would dominate that of the bounds check for the array itself.
>> 
>> Paul.
>> 
>>> On Jan 29, 2018, at 11:37 AM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>> 
>>> I ran with a smaller byte[] initially and saw about a 10% improvement from removing the branch, which is why I felt the superfluous bytes were motivated.
>>> 
>>> /Claes
>>> 
>>> Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> skrev: (29 januari 2018 19:14:44 CET)
>>> 
>>> 
>>>         On Jan 29, 2018, at 9:44 AM, Martin Buchholz
>>>         <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>>>         Thanks. I might try to shrink the size of the static array,
>>>         by only storing values between '0' and 'z', at the cost of
>>>         slightly greater lookup costs for each char.
>>> 
>>>     I was wondering the same, or just clip the end of the array to’z'
>>> 
>>>     if (ch <= ‘z’ && radix …) { // Might even fold the upper bounds check for DIGITS
>>>        value = DIGITS[ch];
>>>        ...
>>>     }
>>> 
>>>     Paul.
>>> 
>>>         On Mon, Jan 29, 2018 at 3:15 AM, Claes Redestad
>>>         <claes.redestad at oracle.com
>>>         <mailto:claes.redestad at oracle.com>> wrote:
>>> 
>>>             Hi, for the latin1 block of CharacterData we can improve
>>>             the digit(int, int) implementation by providing an
>>>             optimized lookup table. This improves microbenchmarks
>>>             exercising Integer.parseInt, Long.parseLong and
>>>             UUID.fromString etc by around 50%for typical inputs.
>>>             Webrev:
>>> http://cr.openjdk.java.net/~redestad/8196331/open.00/
>>> <http://cr.openjdk.java.net/%7Eredestad/8196331/open.00/>
>>>             Bug: https://bugs.openjdk.java.net/browse/JDK-8196331 The
>>>             lookup array is pre-calculated to minimize startup impact
>>>             (adds 1,027 bytecodes executed during initialization) /Claes
>>> 
>>> 
>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> 
>