JEP 254: Compact Strings

Vitaly Davidovich vitalyd at gmail.com
Mon May 18 14:35:40 UTC 2015


>
> From a purely performance perspective, the most expensive CPU operations
> are memory access these days.


Very true ... for random accesses.

Anything that halves memory reads will likely produce better performance.


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.

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[]).

On Mon, May 18, 2015 at 10:24 AM, Rezaei, Mohammad A. <
Mohammad.Rezaei at gs.com> wrote:

> For what it's worth, we would welcome this change. We took a large memory
> hit and a small performance hit when we upgraded from 1.6 to 1.7 in some of
> our memory-bound applications.
>
> From a purely performance perspective, the most expensive CPU operations
> are memory access these days. Anything that halves memory reads will likely
> produce better performance.
>
> From an implementation perspective, having used 1.6's compressed strings
> feature in production, we are comfortable that none of our code, nor any of
> our dependencies rely on String internal representation in such a way as to
> cause a significant backward compatibility issue.
>
> Thanks
> Moh
>
> >-----Original Message-----
> >From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf
> >Of mark.reinhold at oracle.com
> >Sent: Thursday, May 14, 2015 7:05 PM
> >To: xueming.shen at oracle.com
> >Cc: core-libs-dev at openjdk.java.net
> >Subject: JEP 254: Compact Strings
> >
> >New JEP Candidate: http://openjdk.java.net/jeps/254
> >
> >- Mark
>



More information about the core-libs-dev mailing list