Re: Backport of JEP 254 (Compact Strings) to OpenJDK 8

2017-01-12 Thread Aleksey Shipilev
On 01/12/2017 08:11 PM, John Platts wrote: > I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support > backported from OpenJDK 9. I like the compact strings work that is being done > in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254 > suppor

Backport of JEP 254 (Compact Strings) to OpenJDK 8

2017-01-12 Thread John Platts
I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support backported from OpenJDK 9. I like the compact strings work that is being done in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254 support since I am working with Java applications that might

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread John Rose
On Sep 6, 2016, at 2:18 PM, Tim Ellison wrote: > > People stash all sorts of things in (immutable) Strings. Reducing the > limits in JDK9 seems like a regression. Was there any consideration to > using the older Java 8 StringCoding APIs for UTF-16 strings (already >

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread Xueming Shen
On 9/6/16, 2:18 PM, Tim Ellison wrote: Do we have a real use case that impacted by this change? People stash all sorts of things in (immutable) Strings. Reducing the limits in JDK9 seems like a regression. Was there any consideration to using the older Java 8 StringCoding APIs for UTF-16

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread Tim Ellison
On 06/09/16 19:04, Xueming Shen wrote: > On 9/6/16, 10:09 AM, Tim Ellison wrote: >> Has it been noted that while JEP 254 reduces the space occupied by one >> byte per character strings, moving from a char[] to byte[] >> representation universally means that the maximum length of a UTF-16 >> (two

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread Xueming Shen
On 9/6/16, 12:58 PM, Charles Oliver Nutter wrote: On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen > wrote: Yes, it's a known "limit" given the nature of the approach. It is not considered to be an "incompatible change", because

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread John Rose
On Sep 6, 2016, at 12:58 PM, Charles Oliver Nutter wrote: > > On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen > wrote: > >> Yes, it's a known "limit" given the nature of the approach. It is not >> considered >> to be an "incompatible change", because

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread Charles Oliver Nutter
On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen wrote: > Yes, it's a known "limit" given the nature of the approach. It is not > considered > to be an "incompatible change", because the max length the String class > and > the corresponding buffer/builder classes can

Re: JEP 254: Compact Strings - length limits

2016-09-06 Thread Xueming Shen
On 9/6/16, 10:09 AM, Tim Ellison wrote: Has it been noted that while JEP 254 reduces the space occupied by one byte per character strings, moving from a char[] to byte[] representation universally means that the maximum length of a UTF-16 (two bytes per char) string is now halved? Hi Tim, Yes,

Re: JEP 254: Compact Strings thoughts: character ranges outside ASCII + EASCII blocks

2015-09-25 Thread Aleksey Shipilev
Hi Simon, On 09/25/2015 01:01 AM, Simon Spero wrote: > [Some of this is may simple or prohibitively tricksy depending on alignment > constraints (even though it's restricted to Prime Multilingual Plane :-) ] > > For some not un-realistic use cases, the most significant bytes for all the >

JEP 254: Compact Strings thoughts: character ranges outside ASCII + EASCII blocks

2015-09-24 Thread Simon Spero
[Some of this is may simple or prohibitively tricksy depending on alignment constraints (even though it's restricted to Prime Multilingual Plane :-) ] For some not un-realistic use cases, the most significant bytes for all the characters in a string are identical, even if the string is non-latin.

Re: JEP 254: Compact Strings

2015-06-02 Thread Jeremy Manson
TL;DR: In principle, we'd love to do more early testing of Hotspot / JDK features, but our benchmarks are, honestly, not all that great. We end up having to test against live services, which makes this sort of thing really hard. More info than you need: There are two real problems here: 1) To

Re: JEP 254: Compact Strings

2015-06-01 Thread Vitaly Davidovich
Hi Aleksey, While it's true that the denser format will require fewer cachelines, my experience is that most strings are smaller than a single cacheline worth of storage, maybe two lines in some cases; there's just a ton of them in the heap. So the heap footprint should be substantially reduced,

Re: JEP 254: Compact Strings

2015-06-01 Thread 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

Re: JEP 254: Compact Strings

2015-06-01 Thread Aleksey Shipilev
(getting back to this) Hi Jeremy, On 05/16/2015 03:34 AM, Jeremy Manson wrote: So, I'm pretty dubious, mostly because of the risks mentioned in the JEP. If you need a flag-check and two code paths for every String method, that's going to make the String class more slow and bloated, and make

Re: JEP 254: Compact Strings

2015-06-01 Thread Aleksey Shipilev
On 06/01/2015 03:54 PM, Vitaly Davidovich wrote: While it's true that the denser format will require fewer cachelines, my experience is that most strings are smaller than a single cacheline worth of storage, maybe two lines in some cases; there's just a ton of them in the heap. So the heap

Re: JEP 254: Compact Strings

2015-06-01 Thread Vitaly Davidovich
My calculation doesn't assume cacheline granularity; I'm looking at strictly the strings. What's allocated next to/around them is completely arbitrary, circumstantial, uncontrollable to a large extent, and often not repeatable. If you're claiming that some second or even third order locality

RE: JEP 254: Compact Strings

2015-05-18 Thread Rezaei, Mohammad A.
: JEP 254: Compact Strings New JEP Candidate: http://openjdk.java.net/jeps/254 - Mark

Re: JEP 254: Compact Strings

2015-05-18 Thread Vitaly Davidovich
...@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

Re: JEP 254: Compact Strings

2015-05-15 Thread Jeremy Manson
So, I'm pretty dubious, mostly because of the risks mentioned in the JEP. If you need a flag-check and two code paths for every String method, that's going to make the String class more slow and bloated, and make it very difficult for the JIT compiler to do its job inlining and intrinsifying calls

JEP 254: Compact Strings

2015-05-14 Thread mark . reinhold
New JEP Candidate: http://openjdk.java.net/jeps/254 - Mark