On Tue, 10 Oct 2023 10:03:52 GMT, Shaojin Wen <d...@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
