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.
