RFR: 8261847: performace of java.lang.Record::toString should be improved [v3]

[Vicente Romero]

On Sat, 20 Nov 2021 12:10:40 GMT, Jim Laskey <jlaskey at 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