Re: 回复：Propose to remove support for CompactStrings off

Thu Nov 6 18:48:51 UTC 2025

Hi wenshao,

I've written up a draft JEP for deprecating the disabling of Compact Strings. There 
hasn't been a good term for running the system with Compact Strings disabled, so I 
made up a term "UTF-16-only" and used it here.

https://openjdk.org/jeps/8371379

I also filed an enhancement to cover the change to add a warning message when 
-XX:-CompactStrings is used, and I've assigned it to you (wenshao). Not that this 
change can't be integrated until the JEP is moved into the Targeted state.

https://bugs.openjdk.org/browse/JDK-8371431

You might want to associate PR 27995 with this bug report.

s'marks

On 11/3/25 10:04 PM, Stuart Marks wrote:
>
> Hi wenshao,
>
> I think removing Compact Strings is a great idea! As you noted in your first 
> message, removing it would make String easier to maintain. Just so that everybody 
> here understands the issues, every string algorithm has THREE implementations:
>
> 1. compact strings enabled, using ISO Latin 1 coder
>
> 2. compact strings enabled, using UTF-16 coder
>
> 3. compact strings disabled
>
> In recent years I suspect our test coverage of the compact-strings disabled case 
> is lacking, as some bugs have occurred in only that case. For example, see 
> JDK-8321514 <https://bugs.openjdk.org/browse/JDK-8321514>, JDK-8316879 
> <https://bugs.openjdk.org/browse/JDK-8316879>, JDK-8360271 
> <https://bugs.openjdk.org/browse/JDK-8360271>, JDK-8360255 
> <https://bugs.openjdk.org/browse/JDK-8360255>, JDK-8221430 
> <https://bugs.openjdk.org/browse/JDK-8221430>, etc. (Some of these have been 
> fixed, but some are still open.)
>
> As Alan noted, however, we can't simply remove this case. We also can't simply 
> deprecate the command-line option; we need to deprecate the feature of running 
> without Compact Strings before we can remove that feature.
>
> Compact Strings were introduced with JEP 254 <https://openjdk.org/jeps/254>. The 
> JEP doesn't mention that there is an option to disable compact strings, but the 
> JVM Guide 
> <https://docs.oracle.com/en/java/javase/25/vm/java-hotspot-virtual-machine-performance-enhancements.html#GUID-D2E3DC58-D18B-4A6C-8167-4A1DFB4888E4> 
> describes the Compact Strings feature and also the ability to disable it using the 
> -XX:-CompactStrings command line option. This section doesn't say much about when 
> you might want to disable the feature, though; it merely says "This feature can be 
> disabled if you observe performance regression issues in an application." Articles 
> like this one from Baeldung <https://www.baeldung.com/java-9-compact-string>, and 
> vendor documentation from IBM 
> <https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xx-compactstrings> 
> also document this option, but they offer similarly vague advice.
>
> Since the option is fairly well-known, it's not merely a matter of looking at the 
> status of the various ports (though those are significant, of course). It could be 
> that some installations out there running with option to disable compact strings, 
> perhaps if they encountered a performance regression, or for other reasons. 
> They'll need to be informed that the feature is going away, and the best way to do 
> that is with a JEP.
>
> There are some additional issues to consider as well.
>
>   * As Alan noted,  the ARM32 port has compact strings disabled by default. It's
>     not clear whether it even works if compact strings are enabled.
>   * Compact strings increases storage requirements of CJK character data. Our
>     /assumption/ has been that even CJK-heavy applications use a lot of ASCII data
>     for config files, message headers, JSON, etc., and that compact strings are
>     still a net win for such applications. However, that's an assumption. There's
>     the possibility that some installation run those applications with compact
>     strings disabled.
>   * The JNI GetStringCritical call returns a direct pointer in the non compact
>     strings case but makes a copy when compact strings are enabled. Some
>     applications may suffer regressions because of this; see this Stack Overflow
>     <https://stackoverflow.com/questions/76913323/string-compact-has-introduced-some-performance-issues-for-the-current-jni-how>
>     question.
>
> There are probably some other issues we haven't considered yet. The best way to 
> flush them out is to post a JEP, and then use other channels to publicize the JEP. 
> The JEP is mostly a formality about changing the official status of running in the 
> compact-strings-disabled mode to "deprecated". Even though it seems like a lot of 
> overhead to write a JEP for this, the fact is that many people in the tech press 
> look only at the list of JEPs for each release and not much else. Any many Java 
> users look only at tech publications to keep up with Java; they don't look at 
> GitHub or follow the OpenJDK mailing lists. Thus, posting a JEP is the best chance 
> we have to reach a broad set of Java users, some of whom might be affected by this 
> change.
>
> Actual changes that go along with the deprecation will probably only involve 
> adding warning messages and possibly updating documentation. We don't need to 
> resolve issues like the ARM32 port yet. However, that will need to be resolved 
> before we actually remove the feature.
>
> Since I'm "Dr Deprecator" I'll volunteer to draft the JEP.
>
> s'marks
>
>
> On 10/27/25 11:56 PM, Alan Bateman wrote:
>> On 28/10/2025 06:32, wenshao wrote:
>>>
>>> Thanks to Alan for your feedback.
>>>
>>> Based on Chen Liang's suggestion, I submitted a new draft PR 
>>> https://github.com/openjdk/jdk/pull/27995 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27995__;!!ACWV5N9M2RV99hQ!OKe3zURFdlME6esFh_Travsoq4L0s3h71P8bsjCEG5RrmA0nzVmARS7ZAmOZEL0-DWdIg9P8orcXs26SZtYD-c8ZB8h_Fg$> 
>>> to add a warning message to the ComactStrings option.
>>
>> I think  first step has to be establish what or who might be using 
>> -XX:-CompactStrings in 2025. This means looking into the status of ports. Andrew 
>> Haley is going to check with folks in IBM as some of the bug reports for the 
>> -CompactString code paths come from ports there.
>>
>> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/ebf6e9ee/attachment-0001.htm>