On Sat, 20 Nov 2021 12:10:40 GMT, Jim Laskey <jlas...@openjdk.org> wrote:
>> @stuart-marks yes, a general purpose splitting logic moved into the >> `StringConcatFactory` would be able to get rid of the arbitrary 200 slot >> limit (we would hit a harder but less arbitrary limit at around 253 instead). >> >> @JimLaskey I don't see why it wouldn't work generally from the point of view >> of the `StringConcatFactory`: Vicente's code operates on a `MethodHandle[]` >> with getters as inputs to the `SCF` bootstrap method, whereas `SCF` would >> deal with arguments directly (retrieved from an `Object[]`). I think the >> code changes from the patch here after moving the logic into `SCF` should be >> pretty minimal and straightforward: if I'm not missing anything we'd only >> conceptually be replacing the `filterArguments` on line 313 with an >> `insertArguments`. > > @cl4es I was thinking of the more general case 200 < N. You were in the 200 < > N < 253 case. I think it would be better to pass in a chunk size (<= 200) and > an array of ptype and get an array of method handles each taking a chunk size > of arguments plus result of prior call. This is more like what javac does. @JimLaskey I'm generating several recipes one per each invocation of StringConcatFactory::makeConcatWithConstants I think that generating only one recipe is possible only if the number of `getters` we are dealing with is less than the maximum number of slots we want to split the `getters` into ------------- PR: https://git.openjdk.java.net/jdk/pull/6403
