Currently we have an optimization in place when applying a repeated filter so that a specialized LambdaForm is generated and we only bind the filter once to the MH combinator tree:

 var mh = MethodHandles.filterArguments(mh, 0, myFilter, myFilter, myFilter); // a single LF class is generated/resolved

When applying more than one different filter combinator, we'll create a new LF each time the filter changes:

 var mh = MethodHandles.filterArguments(mh, 0, myFilter, otherFilter, myFilter); // 3 LF classes are generated/resolved and the MH is rebound multiple times.

One case where it would be beneficial to generate a customized LF class for all of these that only binds in each filter once is showcased by JDK-8288011: For that RFE I apply distinct filters independently to reduce the number of LF classes to at most 3 (not generally something we can do since it relies on the filters not having any unwanted side-effects).

Being able to get a single customized LF generated in one go could reduce the number of classes generated for String concat stress tests further, but implementation complexity might become an issue.