LambdaFormEditor provides a filterArgumentForm transform which enables compositionally applying simple filters and conversions one by one. Each transform will create a new LambdaForm and rebind with a new BMH species. This facilitates sharing, but has the effect that we might be creating many intermediaries we won't typically use.

By providing a transform which applies the same filter repeatedly on some selected arguments, we can optimize for cases where there are repeated conversions. This allows the runtime to optimize the internal setup of public API methods such as MethodHandles.filterArguments(MethodHandle, int, MethodHandle...) and MethodHandle.asType(MethodType)

Example: mh.asType(mt1) where the mh.type is (JJJJ)I and mt1 is (IIII)I would need to add I->J widening conversions to each argument. Each application of such a conversion C creates a new BMH with a new species, first (JIII)I, with C bound in as a 5th (or 6th, counting the MH) argument, then from that we create (JJII)I with C bound in again as the 6th argument.. and so on.

With the optimization in place we can go from (IIII)I to (JJJJ)I in one step: bind in C as the 5th argument, apply expressions to the LF to call it on each parameter in order. In this example we then end up with only one additional BMH species rather than four.

In synthetic examples invoking methods with maximal number of arguments where all arguments are repeated, the number of intermediary species types and lambda form classes generated can be reduced from up to ~290 to 6 (98% reduction), while in less contrived examples the reduction is more modest, down to no difference in number of shapes generated in completely randomized tests. Repeated filters and conversions are common, for example in the ISC implementation, where this patch reduces the number of shapes and LFs generated in a range of tests.