RFR: 8196331: Optimize Character.digit for latin1 input (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Tue Jan 30 16:29:13 UTC 2018

OK! A surprising increase in code size. Thanks for checking.

Paul.

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.

More information about the core-libs-dev mailing list