On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> To take optimal advantage of the pre-existing optimization for repeated > filters we could split the application of different types of stringifiers. > > The resulting difference in order of evaluation is not observable by > conventional means since all reference type share the same object > stringifier, and the others are filtering primitives (floats and doubles) > which have been passed by value already. > > This change neutral on many concatenation expression shapes, but for any > complex expressions with interleaving float/double and reference parameters > it brings a straightforward reduction in rebinds and underlying LFs > generated. For example on the > [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) > test there's a modest 2% reduction in total classes loaded with this change > (from 16209 to 15872) This looks good to me, but... Looking at the code in MethodHandles::filterArguments, and this optimization. It seems that for multiple filters we could potentially always generate just a single new lambda form if we wanted, not just for repeated filters. It would be similar to `LambdaFormEditor::makeRepeatedFilterForm`. Just need to extend the species data with one new `L_TYPE` field for each unique filter, generate a new getCombiner `Name` for each unique combiner, pass in an array of combiner types instead of just a single one, and pass in an additional array of ints that marks the combiner used by each argument position. Then do similar wiring up as we do now, but calling the corresponding combiner for each argument pos. Right? (If I'm right about that, maybe that's even a more interesting direction to explore, since it would benefit everyone, and the code in StringConcatFactory could stay the same) ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9082
