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

[David Schlosnagle]

On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

src/java.base/share/classes/java/lang/Integer.java line 560:

> 558:         if (radix > Character.MAX_RADIX) {
> 559:             throw NumberFormatException.forMaxRadix(radix);
> 560:         }

It sounds like these methods are now already under the default common inline threshold, but wondering if it would be worthwhile to pull out the radix validation to a separate method.

src/java.base/share/classes/java/lang/NumberFormatException.java line 107:

> 105:     static NumberFormatException forMaxRadix(int radix) {
> 106:         return new NumberFormatException(String.format(
> 107:                 "radix %s greater than Character.MAX_RADIX", radix));

I realize these exception code paths are likely dominated by filling in the stack trace, but I would suggest avoiding `String.format` for these cases where this could just use string concatenation, e.g. see https://github.com/openjdk/jdk/pull/9706

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

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