RFR: 8287292: Improve TransformKey to pack more kinds of transforms efficiently

[Jorn Vernee]

On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 239:

> 237:             for (int i = 0; i < b23456.length; i++) {
> 238:                 int b = b23456[i] & 0xFF;
> 239:                 bitset |= b;

Looks like `b` is always truncated. I wonder what happens if the ints in this array are larger than a byte (which seems to be possible in e.g. the case of argument positions). Some higher order bits might be dropped, but the resulting `b` might only have the least significant 4 bits set.

I think the untruncated value should be used to compute the bitset? `butset |= b23456[i]`? Then the `inRange` check should reject that case.

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

PR: https://git.openjdk.java.net/jdk/pull/8881