Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38500 > unrolled thread

JDK 9 strings very slow

Back to article view | Back to comp.lang.java.programmer

Contents

  JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 15:47 +0200
    Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 15:56 +0200
      Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 16:21 +0200
    Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-07-27 10:11 -0400
      Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 16:23 +0200
        Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 16:25 +0200
    Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-26 09:44 -0700
      Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-08-26 16:36 -0400
        Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-26 23:33 +0200
          Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-08-27 10:31 -0400
            Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-27 19:01 +0200
              Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-27 19:17 +0200
                Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-08-27 13:32 -0400
                  Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-27 10:49 -0700
                    Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-30 18:56 -0700
                      Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-31 00:29 -0700
                        Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-31 09:56 +0200

#38500 — JDK 9 strings very slow

I guess they are kidding:

     public static byte[] toBytes(int[] val, int off, int len) {
         byte[] ret = new byte[len];
         for (int i = 0; i < len; i++) {
             int cp = val[off++];
             if (!canEncode(cp)) {
                 return null;
             }
             ret[i] = (byte)cp;
         }
         return ret;
     }


So the above routine is run for every string,
to check whether it can be latin encoded.

But the routine does allocate a byte[len],
and throws it away when it is not latin.

Are there any benchmarks for these strings?

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/lang/String.java

[toc] | [next] | [standalone]

#38501

So what they wanted to archive, less GC pressure,
they have traded to more GC pressure when there
are really no latin1 strings involved?

I read Closed / Delivered:
http://openjdk.java.net/jeps/254

Is this a joke?

j4n bur53 schrieb:
> I guess they are kidding:
> 
>      public static byte[] toBytes(int[] val, int off, int len) {
>          byte[] ret = new byte[len];
>          for (int i = 0; i < len; i++) {
>              int cp = val[off++];
>              if (!canEncode(cp)) {
>                  return null;
>              }
>              ret[i] = (byte)cp;
>          }
>          return ret;
>      }
> 
> 
> So the above routine is run for every string,
> to check whether it can be latin encoded.
> 
> But the routine does allocate a byte[len],
> and throws it away when it is not latin.
> 
> Are there any benchmarks for these strings?
> 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/lang/String.java 
> 

[toc] | [prev] | [next] | [standalone]

#38503

 From 2017 source OpenJDK:

Corr.:
for the usual char[] constructor it would, this
time in class StringUTF16 and not StringLatin1:


     public static byte[] compress(char[] val, int off, int len) {
         byte[] ret = new byte[len];
         if (compress(val, off, ret, 0, len) == len) {
             return ret;
         }
         return null;
     }

Same problem, a byte array is allocated and then thrown
away. Does this also happen in StringBuilder.toString()?
Lets check:

     public String toString() {
         // Create a copy, don't share the array
         return isLatin1() ? StringLatin1.newString(value, 0, count)
                           : StringUTF16.newString(value, 0, count);

     }


Lets see what it does, StringUTF16.newString:

        if (String.COMPACT_STRINGS) {
             byte[] buf = compress(val, index, len);
             if (buf != null) {
                 return new String(buf, LATIN1);
             }
         }
         int last = index + len;
         return new String(Arrays.copyOfRange(val,
               index << 1, last << 1), UTF16);

Same nonsense again...

j4n bur53 schrieb:
> So what they wanted to archive, less GC pressure,
> they have traded to more GC pressure when there
> are really no latin1 strings involved?
> 
> I read Closed / Delivered:
> http://openjdk.java.net/jeps/254
> 
> Is this a joke?
> 
> j4n bur53 schrieb:
>> I guess they are kidding:
>>
>>      public static byte[] toBytes(int[] val, int off, int len) {
>>          byte[] ret = new byte[len];
>>          for (int i = 0; i < len; i++) {
>>              int cp = val[off++];
>>              if (!canEncode(cp)) {
>>                  return null;
>>              }
>>              ret[i] = (byte)cp;
>>          }
>>          return ret;
>>      }
>>
>>
>> So the above routine is run for every string,
>> to check whether it can be latin encoded.
>>
>> But the routine does allocate a byte[len],
>> and throws it away when it is not latin.
>>
>> Are there any benchmarks for these strings?
>>
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/lang/String.java 
>>
> 

[toc] | [prev] | [next] | [standalone]

#38502

On 7/27/2018 9:47 AM, j4n bur53 wrote:
> I guess they are kidding:
> [... Claim: compressed Strings are "very slow" ...]
> 
> Are there any benchmarks for these strings?

http://cr.openjdk.java.net/~shade/density/state-of-string-density-v1.txt

-- 
esosman@comcast-dot-net.invalid
Nine hundred eight days to go.

[toc] | [prev] | [next] | [standalone]

#38504

They only show Latin1 is faster. Maybe they don't
understand that their UTF16 is simply slower:

StringCompressLogging.cyrillic                                   avgt 
25    81.210 ±   0.334   ns/op
StringCompressLogging.latin                                      avgt 
25    56.337 ±   0.357   ns/op

Thats a very depressing nonsense frankly.

Eric Sosman schrieb:
> On 7/27/2018 9:47 AM, j4n bur53 wrote:
>> I guess they are kidding:
>> [... Claim: compressed Strings are "very slow" ...]
>>
>> Are there any benchmarks for these strings?
> 
> http://cr.openjdk.java.net/~shade/density/state-of-string-density-v1.txt
> 

[toc] | [prev] | [next] | [standalone]

#38505

I guess their JDK 9 UTF16 is slower than the JDK 8.
If I have time, I will check myself.

j4n bur53 schrieb:
> They only show Latin1 is faster. Maybe they don't
> understand that their UTF16 is simply slower:
> 
> StringCompressLogging.cyrillic                                   avgt 
> 25    81.210 ±   0.334   ns/op
> StringCompressLogging.latin                                      avgt 
> 25    56.337 ±   0.357   ns/op
> 
> Thats a very depressing nonsense frankly.
> 
> Eric Sosman schrieb:
>> On 7/27/2018 9:47 AM, j4n bur53 wrote:
>>> I guess they are kidding:
>>> [... Claim: compressed Strings are "very slow" ...]
>>>
>>> Are there any benchmarks for these strings?
>>
>> http://cr.openjdk.java.net/~shade/density/state-of-string-density-v1.txt
>>
> 

[toc] | [prev] | [next] | [standalone]

#38562

Is continues deduplication realized and now
part of Java? I read here a long concept with
a lot of alternatives:

   JEP 192: String Deduplication in G1
   http://openjdk.java.net/jeps/192

But if I follow the ticket JDK-8046182 it says
only closed/delivered without more specifics, and
forrest of further tickets.

But there might be no guarantee that for
example Android does the same deduplication
of runtime created strings, right?
   
Am Freitag, 27. Juli 2018 15:47:26 UTC+2 schrieb j4n bur53:
> I guess they are kidding:
> 
>      public static byte[] toBytes(int[] val, int off, int len) {
>          byte[] ret = new byte[len];
>          for (int i = 0; i < len; i++) {
>              int cp = val[off++];
>              if (!canEncode(cp)) {
>                  return null;
>              }
>              ret[i] = (byte)cp;
>          }
>          return ret;
>      }
> 
> 
> So the above routine is run for every string,
> to check whether it can be latin encoded.
> 
> But the routine does allocate a byte[len],
> and throws it away when it is not latin.
> 
> Are there any benchmarks for these strings?
> 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/lang/String.java

[toc] | [prev] | [next] | [standalone]

#38563

On 8/26/2018 12:44 PM, bursejan@gmail.com wrote:
> Is continues deduplication realized and now
> part of Java? I read here a long concept with
> a lot of alternatives:
> 
>     JEP 192: String Deduplication in G1
>     http://openjdk.java.net/jeps/192
> 
> But if I follow the ticket JDK-8046182 it says
> only closed/delivered without more specifics, and
> forrest of further tickets.

     The JEP link says

	Release	8u20

... and the ticket says

	Fix Version/s: 8u20

> But there might be no guarantee that for
> example Android does the same deduplication
> of runtime created strings, right?

     It's my (possibly imperfect) understanding that Android
uses its own, separate JVM implementation.  Changes made to
Oracle's JVM would thus not reach Android "automatically."

     Consider, though, that the various "contents of memory"
studies done in connection with the JEP were quite likely
conducted on server (or server-like) applications, while
Android code is more likely to be client-facing.  There's
no /a priori/ reason to think their memory profiles are
the same, nor that an optimization for one would necessarily
be an optimization for the other.

-- 
esosman@comcast-dot-net.invalid
Eight hundred seventy-eight days to go.

[toc] | [prev] | [next] | [standalone]

#38564

Hi,

Which kind of algorithm was implemented in
8u20 ? There were like 2-4 different
approaches mentioned in the Change.

For example you can mod:

    String.equals()
    String.compareTo()

And overwrite:

    alfa.value = beta.value

And thus remove duplicates of the char[]
array. But the new Strings are anyway
byte[] so all metrics would be different.

Other algorithms despite the above
would require maybe extra worker
threads, which might not be desired...

Bye

Eric Sosman schrieb:
> On 8/26/2018 12:44 PM, bursejan@gmail.com wrote:
>> Is continues deduplication realized and now
>> part of Java? I read here a long concept with
>> a lot of alternatives:
>>
>>     JEP 192: String Deduplication in G1
>>     http://openjdk.java.net/jeps/192
>>
>> But if I follow the ticket JDK-8046182 it says
>> only closed/delivered without more specifics, and
>> forrest of further tickets.
> 
>      The JEP link says
> 
>      Release    8u20
> 
> ... and the ticket says
> 
>      Fix Version/s: 8u20
> 
>> But there might be no guarantee that for
>> example Android does the same deduplication
>> of runtime created strings, right?
> 
>      It's my (possibly imperfect) understanding that Android
> uses its own, separate JVM implementation.  Changes made to
> Oracle's JVM would thus not reach Android "automatically."
> 
>      Consider, though, that the various "contents of memory"
> studies done in connection with the JEP were quite likely
> conducted on server (or server-like) applications, while
> Android code is more likely to be client-facing.  There's
> no /a priori/ reason to think their memory profiles are
> the same, nor that an optimization for one would necessarily
> be an optimization for the other.
> 

[toc] | [prev] | [next] | [standalone]

#38565

On 8/26/2018 5:33 PM, j4n bur53 wrote:
> Hi,
> 
> Which kind of algorithm was implemented in
> 8u20 ? There were like 2-4 different
> approaches mentioned in the Change.

     Do you mean the approaches mentioned in the "Alternatives"
section?  It appears to me that they are listed merely to show
that they were considered -- and each is accompanied by a "Why
this wouldn't be good" summary.  That is, the "Alternatives"
are the *rejected* approaches.

-- 
esosman@comcast-dot-net.invalid
Eight hundred seventy-seven days to go.

[toc] | [prev] | [next] | [standalone]

#38566

Ok, I guess I will try the option:

    PrintStringDeduplicationStatistics

To see what is happening...

Eric Sosman schrieb:
> On 8/26/2018 5:33 PM, j4n bur53 wrote:
>> Hi,
>>
>> Which kind of algorithm was implemented in
>> 8u20 ? There were like 2-4 different
>> approaches mentioned in the Change.
> 
>      Do you mean the approaches mentioned in the "Alternatives"
> section?  It appears to me that they are listed merely to show
> that they were considered -- and each is accompanied by a "Why
> this wouldn't be good" summary.  That is, the "Alternatives"
> are the *rejected* approaches.
> 

[toc] | [prev] | [next] | [standalone]

#38567

But I still see some problems with this approach,
like for example. Did Java amend equals, and like
do a check alfa.value==beta.value ?

I only find in JDK 8:

         if (this == anObject) {
             return true;
         }
         if (anObject instanceof String) {
             String anotherString = (String)anObject;
             int n = value.length;
             if (n == anotherString.value.length) {
                 char v1[] = value;
                 char v2[] = anotherString.value;
                 int i = 0;
                 while (n-- != 0) {
                     if (v1[i] != v2[i])
                         return false;
                     i++;
                 }
                 return true;
             }
         }
         return false;

But if more Strings are deduplicated,
and as I understand then only the char[]
is elemeninated, the JEP writes:

"When deduplicating, a lookup is made in this
table to see if there is already an identical
character array somewhere on the heap."

So the above could profit from an
additional code line:

    if (value==anotherString.value)
         return true;

Maybe this was done in JDK 9. Further my code
could profit from more deduplication, since
the JEP method doesn't deduplicate the

object gutter. There will be still space
needed for the Sring object around the
character array. And I have a use case

where I compare a lot of identical objects.
Cant help it at the moment making the code
simpler, but somehow it happens that have an

index key, and then a redundant check of the
same key over a collection. So all these checks
could profit if I manage to go into the

branch if (this == anObject) of the String
equality test. Baha, lets see what can be done,
I have an idea how to deduplicate the object

gutter via the index I have anyway and
this would also work for Android... Ha Ha

Bye

j4n bur53 schrieb:
> Ok, I guess I will try the option:
> 
>     PrintStringDeduplicationStatistics
> 
> To see what is happening...
> 
> Eric Sosman schrieb:
>> On 8/26/2018 5:33 PM, j4n bur53 wrote:
>>> Hi,
>>>
>>> Which kind of algorithm was implemented in
>>> 8u20 ? There were like 2-4 different
>>> approaches mentioned in the Change.
>>
>>      Do you mean the approaches mentioned in the "Alternatives"
>> section?  It appears to me that they are listed merely to show
>> that they were considered -- and each is accompanied by a "Why
>> this wouldn't be good" summary.  That is, the "Alternatives"
>> are the *rejected* approaches.
>>
> 

[toc] | [prev] | [next] | [standalone]

#38568

On 8/27/2018 1:17 PM, j4n bur53 wrote:
> But I still see some problems with this approach,
> like for example. Did Java amend equals, and like
> do a check alfa.value==beta.value ?
> 
> I only find in JDK 8:
> 
>          if (this == anObject) {
>              return true;
>          }
>          if (anObject instanceof String) {
>              String anotherString = (String)anObject;
>              int n = value.length;
>              if (n == anotherString.value.length) {
>                  char v1[] = value;
>                  char v2[] = anotherString.value;
>                  int i = 0;
>                  while (n-- != 0) {
>                      if (v1[i] != v2[i])
>                          return false;
>                      i++;
>                  }
>                  return true;
>              }
>          }
>          return false;

     This Java source code may be somewhat misleading.  I'm not
certain, but here and there in the discussion-and-issue pages
you'll find references to "the HotSpot VM's intrinsic string
operations" -- which suggests (to me) that the JVM might have
its own internal native implementations of some String methods.
The visible Java code might not execute at all, or might execute
only on JVM's that don't "internal-ize" quite so aggressively.

     Permit me to ask: Why are the internals of the JVM's String
handling of such interest to you?  Is it just laudable curiosity,
or are you confronting a difficulty of some kind?

-- 
esosman@comcast-dot-net.invalid
Eight hundred seventy-seven days to go.

[toc] | [prev] | [next] | [standalone]

#38569

I wrote the problem case already, needless to say 
the key is a String, and "same key" does not mean 
pointer == equivalence but only equals() equivalence:

  "but somehow it happens that have an
  index key, and then a redundant check 
  of the same key over a collection."

But I have some ideas to circumvent the problem, so 
that it is woould be also solved for the Android
platform. Will try in the next days...

Still I am currious what the non-Android platform
exactly does, because well, also if I do this
additional deduplication, for the non-Android 

platform the performance of this platform, is 
also directly seen in everything what I do, since 
its part of some core routine that is repeatedly 

and very often called...

So I am at a point where:

   metal = Strings

Ha Ha

Am Montag, 27. August 2018 19:32:48 UTC+2 schrieb Eric Sosman:
> On 8/27/2018 1:17 PM, j4n bur53 wrote:
> > But I still see some problems with this approach,
> > like for example. Did Java amend equals, and like
> > do a check alfa.value==beta.value ?
> > 
> > I only find in JDK 8:
> > 
> >          if (this == anObject) {
> >              return true;
> >          }
> >          if (anObject instanceof String) {
> >              String anotherString = (String)anObject;
> >              int n = value.length;
> >              if (n == anotherString.value.length) {
> >                  char v1[] = value;
> >                  char v2[] = anotherString.value;
> >                  int i = 0;
> >                  while (n-- != 0) {
> >                      if (v1[i] != v2[i])
> >                          return false;
> >                      i++;
> >                  }
> >                  return true;
> >              }
> >          }
> >          return false;
> 
>      This Java source code may be somewhat misleading.  I'm not
> certain, but here and there in the discussion-and-issue pages
> you'll find references to "the HotSpot VM's intrinsic string
> operations" -- which suggests (to me) that the JVM might have
> its own internal native implementations of some String methods.
> The visible Java code might not execute at all, or might execute
> only on JVM's that don't "internal-ize" quite so aggressively.
> 
>      Permit me to ask: Why are the internals of the JVM's String
> handling of such interest to you?  Is it just laudable curiosity,
> or are you confronting a difficulty of some kind?
> 
> -- 
> esosman@comcast-dot-net.invalid
> Eight hundred seventy-seven days to go.

[toc] | [prev] | [next] | [standalone]

#38585

I guess jumping major release numbers from 
JDK 9, JDK 10, JDK 11 hasn't done anything
good. Basically this fine gem of JDK 8

is still not paralleled. I did some measurement
with JDK 11 vs JDK 8. JDK 11 has still awful
heap performance:

    JDK  8: ca.   9000 ms
    JDK 11: ca.  14000 ms

Exact same code...

Am Montag, 27. August 2018 19:50:12 UTC+2 schrieb burs...@gmail.com:
> So I am at a point where:
> 
>    metal = Strings

[toc] | [prev] | [next] | [standalone]

#38586

I tried Graal VM, just used the link from here,
which provided me a Graal Java installation, i.e.
javac, java, etc.. but only with Graal VM.

  Top 10 Things To Do With GraalVM
  https://chrisseaton.com/truffleruby/tenthings/

The preparatory cold run took a little bit 
more time, but then the end result was:

    JDK   8: ca.   9000 ms
    Graal 8: ca.   9000 ms
    JDK  11: ca.  14000 ms

Maybe the good GC performance will be 
preserved inside GraalVM in the future. 
IBM JDK 7.1 I could also download but there 

was a crypt padding error, couldn't run any 
tests. And an IBM JDK 8 I could not yet 
find for non-linux. 

Am Freitag, 31. August 2018 03:56:20 UTC+2 schrieb burs...@gmail.com:
> I guess jumping major release numbers from 
> JDK 9, JDK 10, JDK 11 hasn't done anything
> good. Basically this fine gem of JDK 8
> 
> is still not paralleled. I did some measurement
> with JDK 11 vs JDK 8. JDK 11 has still awful
> heap performance:
> 
>     JDK  8: ca.   9000 ms
>     JDK 11: ca.  14000 ms
> 
> Exact same code...
> 
> Am Montag, 27. August 2018 19:50:12 UTC+2 schrieb burs...@gmail.com:
> > So I am at a point where:
> > 
> >    metal = Strings

[toc] | [prev] | [next] | [standalone]

#38587

Zulu from Azul is also in the slow camp. Just
tested with zulu11.1+23-ea-jdk11-macosx_x64,
the list now reads:

       JDK   8: ca.   9000 ms
       Graal 8: ca.   9000 ms
       JDK  11: ca.  14000 ms
       Zulu 11: ca.  14000 ms

bursejan@gmail.com schrieb:
> I tried Graal VM, just used the link from here,
> which provided me a Graal Java installation, i.e.
> javac, java, etc.. but only with Graal VM.
> 
>    Top 10 Things To Do With GraalVM
>    https://chrisseaton.com/truffleruby/tenthings/
> 
> The preparatory cold run took a little bit
> more time, but then the end result was:
> 
>      JDK   8: ca.   9000 ms
>      Graal 8: ca.   9000 ms
>      JDK  11: ca.  14000 ms
> 
> Maybe the good GC performance will be
> preserved inside GraalVM in the future.
> IBM JDK 7.1 I could also download but there
> 
> was a crypt padding error, couldn't run any
> tests. And an IBM JDK 8 I could not yet
> find for non-linux.
> 
> Am Freitag, 31. August 2018 03:56:20 UTC+2 schrieb burs...@gmail.com:
>> I guess jumping major release numbers from
>> JDK 9, JDK 10, JDK 11 hasn't done anything
>> good. Basically this fine gem of JDK 8
>>
>> is still not paralleled. I did some measurement
>> with JDK 11 vs JDK 8. JDK 11 has still awful
>> heap performance:
>>
>>      JDK  8: ca.   9000 ms
>>      JDK 11: ca.  14000 ms
>>
>> Exact same code...
>>
>> Am Montag, 27. August 2018 19:50:12 UTC+2 schrieb burs...@gmail.com:
>>> So I am at a point where:
>>>
>>>     metal = Strings
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web