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