RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong

[Shaojin Wen]

On Tue, 10 Oct 2023 10:22:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> parseInt & parseLong are accelerated by this code, the key code is here
>> 
>> class DecimalDigits {
>>     public static int digit(byte ch) {
>>         return DIGITS_LATIN1[ch & 0xFF]; // If remove & 0xFF it won't get faster
>>     }
>> }
>> 
>> 
>> This optimization can only be done when radix is fixed.
>
> You are right, JIT profiles are based on bytecode, and by not sharing the code path with generic-radix parseInt, JIT can better optimize the base-10 path.
> 
> In addition, is `(digit = value[i++] - '0') >= 0 && digit <= 9` slower than a table lookup? Don't think you actually need that digit table.

-Benchmark          (size)  Mode  Cnt  Score   Error  Units (baseline)
-Integers.parseInt     500  avgt   15  2.474 ? 0.014  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units (non-lookup table)
+Integers.parseInt     500  avgt   15  2.376 ? 0.018  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units (current f6828ff)
+Integers.parseInt     500  avgt   15  2.267 ? 0.011  us/op

(digit = value[i++] - '0') >= 0 && digit <= 9 slower than a table lookup (current version f6828ff), but faster than base line

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1352837006