Поддержка сжатия сжатых строк в JSM HotSpot?

Ответ 1

Первоначально эта опция была добавлена ​​для улучшения производительности SPECjBB. Достижения обусловлены снижением требований к пропускной способности памяти между процессором и DRAM. Загрузка и сохранение байтов в байте [] потребляет 1/2 полосы пропускания по сравнению с символами в char [].

Однако это происходит по цене. Код должен определить, является ли внутренний массив байтом [] или char []. Это занимает процессорное время, и если рабочая нагрузка не ограничена пропускной способностью, это может привести к регрессии производительности. Существует также цена обслуживания кода из-за дополнительной сложности.

Поскольку не было достаточной рабочей нагрузки, которая показала значительную прибыль (кроме, быть может, SPECjBB), опция была удалена.

Для этого есть еще один угол. Опция уменьшает использование кучи. Для применимых строк это уменьшает использование памяти этих строк на 1/2. Этот угол не учитывался во время удаления опции. Для рабочих нагрузок, размер памяти емкость ограничен (т.е. Должен работать с ограниченным пространством кучи, а GC занимает много времени), этот параметр может оказаться полезным.

При наличии достаточного объема памяти емкость ограниченных рабочих нагрузок, чтобы оправдать включение опции, возможно, вариант будет возвращен.

Редактировать 3/20/2013: Среднее количество кучи сервера использует 25% пространства в строках. Большинство строк являются сжимаемыми. Если опция повторно введена, она может сэкономить половину этого пространства (например, ~ 12%)!

Редактировать 3/10/2016: Функция, похожая на сжатые строки, возвращается в JDK 9 JEP 254.

Ответ 2

Поскольку у меня были голоса, я полагаю, что я не пропустил ничего очевидного, поэтому я зарегистрировал его как ошибку (по крайней мере, бездействие в документации)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129417

(Должно быть видимым через пару дней)

Ответ 3

Просто добавьте для тех, кого это интересует...

Интерфейс java.lang.CharSequence (который реализуется java.lang.String), допускает более компактные представления строк, чем UTF-16.

Приложения, которые манипулируют множеством строк, вероятно, должны быть записаны для принятия CharSequence, так что они будут работать с java.lang.String или более компактными представлениями.

8-битная (UTF-8) или даже 5, 6 или 7-битная или даже сжатая строка может быть представлена ​​как CharSequence.

CharSequence также может быть намного более эффективным для манипулирования - подпоследовательности могут быть определены как представления (указатели) на исходное содержимое, например, вместо копирования.

Например, в concurrent-trees, дерево суффикса десяти пьес Шекспира, требует 2 ГБ ОЗУ с использованием узлов CharSequence, а потребует 249 ГБ ОЗУ при использовании char [] или узлов на основе String.

Ответ 4

Java 9 выполняет сортировку строк огромного файла file.txt в java в два раза быстрее на моей машине, чем на Java 6, а также нуждается только в 1 ГБ памяти, поскольку она -XX:+CompactStrings включен по умолчанию. Кроме того, в Java 6 сжатые строки обрабатывались только для 7-разрядных символов ASCII, тогда как в Java 9 он поддерживает Latin1 (ISO-8859-1). Однако некоторые операции, такие как charAt(idx), могут быть немного медленнее. Благодаря новому дизайну они могут также поддерживать другие кодировки в будущем.

Я написал информационный бюллетень об этом на Информационный бюллетень специалистов Java.

Ответ 5

В OpenJDK 7 (1.7.0_147-icedtea, Ubuntu 11.10), JVM просто терпит неудачу с

Нераспознанная опция VM 'UseCompressedStrings'

когда JAVA_OPTS (или в командной строке) содержит -XX:+UseCompressedStrings.

Кажется, что Oracle действительно удалил эту опцию.