Java9 でも String クラスがリファクタリングされていました （JEP 254: Compact Strings 編） - 地平線に行く

本日、ついに JavaSE 9 がリリースされました！ そこで、かねてから噂になっていた JEP 254: Compact Strings がどのように実装されているのか調べてみました。 Compact Strings の概要 これまで String クラスや StringBuilder クラスなどの内部では、文字列を UTF-16 でエンコードして char 配列で保持していました。 つまり、一文字あたり*1常に char ひとつ = 2バイト分のメモリを使っていました。 しかし、これだと 1 バイトで表せる LATIN1（ASCII コード ＋ ラテン文字）の文字列の場合、その半分が 0x00 になるという無駄がありました。 そこで、内部表現を変更し、文字列が LATIN1 のみで構成されるときは 1 文字を 1 バイトで保持するようにリファクタリングされました。 ちなみに、LATIN

[ka-ka_xyz]

http://openjdk.java.net/jeps/254 "Optimizing character storage for memory may well come with a trade-off in terms of run-time performance." 英語圏の人的にはドンマイドンマイ的な。まあ"trade-off"っていっても利益しか受けない人たちだからぬ

[kz78]

なんか、１バイト文字を効率よく扱うために、2バイト文字の取り扱いに地雷を仕込んでるように見えるが…。

[sifue]

Stringというありふれたクラスでもいまだに改善され続けているのだなぁ。

[yusuke-k]

よい記事だけど、これはリファクタリングではなくてチューニングでは？

[MtAsuka]

中身によって処理を変えるということ自体がUnicodeの取り扱いとしてイマイチだと思うけど、そこまでしてヒープを節約しなければならないんだろうか？

[mongrelP]

英語環境ならいいけどマルチバイト環境だと何か引っかかりそうでこわい。

[wushi]

うえっへぇ・・・

[sonots]

latin1で作っていって範囲外だったら廃棄してUTF8で作り直しかー

[tzik-tack]

BlinkのStringと同じ構造だ

[hiroshitoda]

黒魔術的なVMオプションが爆誕した

[ksakae1216]

面白い記事だ！！

[nnnnnhisakun]

「全体としては、英語圏であれば確実にパフォーマンスが良くなりそうだなーと思った一方、日本語圏だとパフォーマンスが大丈夫なのか気になりました。」

[mizoguche]

“日本語が含まれた文字列は思っているほど多くないと思いますが、もし徹底的にチューニングしたいということであれば Compact Strings​ の有効/無効を切り替えて、どちらがパフォーマンスが良いか調べてみるのもあり”