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

[Chen Liang]

On Tue, 10 Oct 2023 10:03:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Integer.java line 682:
>> 
>>> 680:      */
>>> 681:     public static int parseInt(String s) throws NumberFormatException {
>>> 682:         if (s != null && s.coder() == String.LATIN1) {
>> 
>> Does this code block actually speed up `parseInt`? I recommend you remove this code block and test `parseInt` and `parseLong` again only with new NumberFormatException factories.
>
> 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.

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

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