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