On Tue, 7 Feb 2023 19:12:38 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> It might be that the redundant checks in Arrays.copyOfRange would be > eliminated properly with more inlining, and that the issue here is that the > affected String constructor is particularly gnarly. This gnarliness is due 1) > the need to construct the value and coder in one go and 2) the lack of > multiple return values. Give me a value-based record type so we can split > apart the constructor into charset-specific methods with zero overhead and we > might be able to split up the logic into better-sized chunks. I'm wondering if another contributing factor to the complexity of this code is the continued support of the non-compact-String codepaths. This means there are actually three code paths through every string computation. Do we need to continue to support the non-compact-string code paths? I'm concerned about maintainability too. ------------- PR: https://git.openjdk.org/jdk/pull/12453
