Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: JDK 9 strings very slow
Date: Sun, 26 Aug 2018 16:36:08 -0400
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <plv2vr$59l$1@dont-email.me>
References: <pjf7p5$mul$1@news.albasani.net> <a015ddd6-0716-467d-9e4a-4dfef8939afd@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 26 Aug 2018 20:36:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="70b400ca3f7981dc2e9c5c3400366c66"; logging-data="5429"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18JbGSQAmKvJiPuh2yuQ3vK"
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
Cancel-Lock: sha1:eKjca+JLdcfJtefx0dscOjd6TfI=
In-Reply-To: <a015ddd6-0716-467d-9e4a-4dfef8939afd@googlegroups.com>
Content-Language: en-US
Xref: csiph.com comp.lang.java.programmer: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.