On Thu, 12 Oct 2023 02:24:20 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> More explicitly I was thinking something like below. >> >> I do wonder if some of the benchmark tests should cover the exceptional >> cases. I have seen many systems where attempting to try and parse >> potentially invalid inputs can hit expensive NumberFormatException fallbacks >> (though `-XX:+OmitStackTraceInFastThrow` may eventually kick in). [Guava >> offers `Integer >> Ints.tryParse(String)`](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)) >> and similar to avoid the exception overhead at the cost of boxing for happy >> path of valid `int` and `null` for invalid. >> >> >> checkCanParseLength(s); >> checkCanParseRadix(radix); >> int len = s.length(); >> >> >> private static void checkCanParseLength(String s) { >> if (s == null) { >> throw NumberFormatException.forNull(); >> } >> >> if (s.isEmpty()) { // would be interesting to see if this is >> equivalent to `s.length() == 0` for happy paths >> throw NumberFormatException.forEmpty(); >> } >> } >> >> private static void checkCanParseRadix(int radix) { >> if (radix < Character.MIN_RADIX) { >> throw NumberFormatException.forMinRadix(radix); >> } >> >> if (radix > Character.MAX_RADIX) { >> throw NumberFormatException.forMaxRadix(radix); >> } >> } > > In addition to FreqInlineSize 325, there are other reasons that affect > inlining. If inlining fails, there will be one more method call, making it > slower. This PR does not optimize the scenario where inputting illegal values leads to exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1355987122
