On Mon, 6 May 2024 20:48:05 GMT, Chen Liang <li...@openjdk.org> wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has > a few issues: > 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to > use "newarray code" > 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to > throw IAE and added tests. > 3. `from(Class)` can be slow due to descriptor computation: added benchmark, > will share result in next comment (as it may change with code changes). > > The first 2 changes involves API changes, and a CSR has been created. > Requesting @asotona for a review. The initial benchmark results: Base: Benchmark (type) Mode Cnt Score Error Units TypeKindBench.fromClassDescs PRIMITIVE avgt 6 124.948 ± 3.414 ns/op TypeKindBench.fromClassDescs REFERENCE avgt 6 73.142 ± 1.405 ns/op TypeKindBench.fromClasses PRIMITIVE avgt 6 228.539 ± 8.942 ns/op TypeKindBench.fromClasses REFERENCE avgt 6 2104.329 ± 48.242 ns/op Head: Benchmark (type) Mode Cnt Score Error Units TypeKindBench.fromClassDescs PRIMITIVE avgt 6 128.039 ± 4.121 ns/op TypeKindBench.fromClassDescs REFERENCE avgt 6 58.395 ± 1.197 ns/op TypeKindBench.fromClasses PRIMITIVE avgt 6 228.113 ± 4.167 ns/op TypeKindBench.fromClasses REFERENCE avgt 6 16.450 ± 0.315 ns/op Visual: https://jmh.morethan.io/?gists=ceaeae3775585034817f54b9010a16e3,80570ce8b74ec5a2dffc48c116899aa6 Seems checking `isPrimitive` is always faster than checking the initial char of the descriptor string, so both ClassDesc and Class versions benefit from the `isPrimitive` fast path while the primitive paths don't see significant slowdowns. Of course the Class version benefits more as it avoids computing descriptor strings altogether. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2096895115
