On Sat, 20 Nov 2021 11:31:41 GMT, Claes Redestad <redes...@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
