JEP 254: Compact Strings

[Aleksey Shipilev]

On 05/18/2015 05:35 PM, Vitaly Davidovich wrote:
> This part is a bit unclear for the proposed changes.  While it's true that
> single byte encoding will be denser than two byte, most string ops end up
> walking the backing store linearly; prefetch (either implicit h/w or
> software-assisted) could hide the memory access latency.

It will still pollute the caches though, and generally incur more
instructions to be executed (e.g. think about the vectorized scan of the
char[] array -- the compressed version will take 2x less instructions).


> Personally, what I'd like to see is fusing storage of String with its
> backing data, irrespective of encoding (i.e. removing the indirection to
> fetch the char[] or byte[]).

This is not the target for this JEP, and the groundwork for
String-char[] fusion is handled elsewhere (I put my hopes at Valhalla
that will explore the exact path to add the "exotic" object shapes into
the runtime).

String-char[] fusion neither conflicts with the Compact String
optimization, nor provides the alternative. Removing the "excess"
headers from backing char[] array would solve the "static" overhead in
Strings, while the String compaction would further compact the backing
storage.

Thanks,
-Aleksey.