RFR: 8287522: StringConcatFactory: Add in prependers and mixers in batches

[Claes Redestad]

On Mon, 23 May 2022 20:03:05 GMT, Claes Redestad <redestad at 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