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

[PROgrm_JARvis]

On Sat, 20 Nov 2021 04:40:22 GMT, Stuart Marks <smarks 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`.

Too me it looks as if it something that has to be considered as part of the specification, at least in the current state.
The [Javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html#makeConcat(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType)) explicitly states that:

> <...> the following linkage invariants must hold:
> - The number of parameter slots in `concatType` is less than or equal to 200
> <...>
> **Throws**:
> `StringConcatException` - If any of the linkage invariants described here are violated, or the lookup context does not have private access privileges.

If it was an unspecified implementation detail, than arbitrary compilers (at least if we speak about `javac`) would have no formal reason to stick to this limit instead of using max available number of slots, which currently would lead to runtime `StringConcatException`.

For this reason the current state (IMO) should be considered the part of the specification and thus it seems reasonable to either:
- make it available to other code (via a public constant, at least)
- remove the magical number limit (as suggested by @stuart-marks and @cl4es) so that compilers no longer have to depend on a semi-specified magical number
- add an analog of current `StringConcatFactory` to some other place (`java.lang.runtime` seems to be a nice place, considering how most new `invokedynamic`-related bootstraps live there) but make it more strictly specified and keep the current `StringConcatFactory` untouched (simply delegating to the new one)

---

I understand that this is mostly out of this PR's scope and should definitely be discussed more wisely but I guess that it's worth starting this discussion here where it can be seen as an issue.

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

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