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
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
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
>
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
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
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
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
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
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,
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
>
[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.
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
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,
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
(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
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
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
: JEP 254: Compact Strings
New JEP Candidate: http://openjdk.java.net/jeps/254
- Mark
...@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
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
New JEP Candidate: http://openjdk.java.net/jeps/254
- Mark
21 matches
Mail list logo