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

[Jim Laskey]

On Sat, 20 Nov 2021 11:31:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Regarding the slot limit in `StringConcatFactory`, it's not clear to me the limit of 200 is normative or is merely an implementation note. The limit of 200 slots seems to be arbitrary and shouldn't be baked into the spec. Perhaps this limit can be removed if the splitting logic is moved into `StringConcatFactory`.
>
> @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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6403