RFR: 8331744: java.lang.classfile.TypeKind improvements

[Chen Liang]

On Mon, 6 May 2024 20:48:05 GMT, Chen Liang <liach at 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