On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad <redes...@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
