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

Groups > comp.lang.java.programmer > #38564

Re: JDK 9 strings very slow

Show all headers | View raw

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.
> 

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web