On Mon, 23 May 2022 20:03:05 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> When generating `MethodHandle`-based concatenation expressions in > `StringConcatFactory` we can reduce the number of classes generated at > runtime by creating small batches of prependers and mixers before binding > them into the root expression tree. > > Improvements on one-off tests are modest, while the improvement on > bootstrapping stress tests can be substantial > ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)): > > | Build | # classes | Runtime | > | ----------- | ----------------- | --------------- | > | Baseline | 31119 | 2.942s | > | Patch | 16208 | 1.958s | > > An earlier version of this patch saw a regression in the > `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along > with the optimizations in #8881 and #8923 that is no longer the case, and > allocation pressure is down slightly compared to the baseline on such a > repeat-the-same-bootstrap stress test: > > Baseline: > > Benchmark Mode Cnt > Score Error Units > SCFB.makeConcatWithConstants avgt 5 > 2170.039 ? 117.441 ns/op > SCFB.makeConcatWithConstants:?gc.alloc.rate.norm avgt 5 > 3538.020 ? 4.558 B/op > > This patch: > > Benchmark Mode Cnt > Score Error Units > SCFB.makeConcatWithConstants avgt 5 > 2144.807 ? 162.685 ns/op > SCFB.makeConcatWithConstants:?gc.alloc.rate.norm avgt 5 > 3184.943 ? 4.495 B/op Before moving forward with this I've been looking at slightly more expensive bootstrapping of already known shapes. On one such bootstrap microbenchmark, `StringConcatFactoryBootstraps` this patch would cause a ~25% slowdown (and a 33% increase in allocations). Not too concerning, but since the purpose of this patch is to reduce String concat bootstrapping overhead it would be nice to not trade that for a localized regression. First improvement was to pack `TransformKey`s better: #8881 - which helps both variants, but doesn't really narrow the gap. We can improve further outside of `StringConcatFactory` to prepare for this RFE by reducing the number List-to-array and array-to-List conversions in `MethodHandles.dropArguments` (-280b/op). Another candidate is to turn `LambdaFormEditor` either into a static utility or it into `LamdaForm` proper (TBD if this is worthwhile; they're tightly coupled, and all state maintained by `LambdaFormEditor` lives in `LambdaForm`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8855
