RFR: 8301958: Avoid Arrays.copyOfRange overhead in java.lang.String [v5]

[Claes Redestad]

On Tue, 7 Feb 2023 19:24:11 GMT, Stuart Marks <smarks at 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.

I think most apps have sufficient ASCII/latin1-encodable data to make compact strings a net win. Especially with recent improvements to key intrinsics that has narrowed the gap. 

I still think turning off compact strings might be beneficial in locales where most strings are UTF-16, but as you say there might be wins to maintainability and code complexity by ripping out `-XX:-CompactStrings` (which could mean a net performance win for all).

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

PR: https://git.openjdk.org/jdk/pull/12453