> > 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.rez...@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-boun...@openjdk.java.net] On > Behalf > >Of mark.reinh...@oracle.com > >Sent: Thursday, May 14, 2015 7:05 PM > >To: xueming.s...@oracle.com > >Cc: core-libs-dev@openjdk.java.net > >Subject: JEP 254: Compact Strings > > > >New JEP Candidate: http://openjdk.java.net/jeps/254 > > > >- Mark >
