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

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

how actually string store in java machine

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

Contents

  how actually string store in java machine Rishipal Singh <95rishipal@gmail.com> - 2014-03-25 09:56 -0700
    Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-25 10:32 -0700
    Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-25 10:33 -0700
    Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 13:49 -0400
      Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-25 20:29 +0100
        Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-25 20:31 +0100
          Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-25 19:37 -0700
            Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-26 09:03 +0100
              Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-26 09:11 +0100
              Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-27 10:27 +0100
            Re: how actually string store in java machine markspace <markspace@nospam.nospam> - 2014-03-26 08:32 -0700
              Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-26 13:54 -0400
                Re: how actually string store in java machine taqmcg@gmail.com - 2014-03-26 12:57 -0700
                Re: how actually string store in java machine markspace <markspace@nospam.nospam> - 2014-03-26 16:37 -0700
                  Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-27 08:54 -0400
                    Re: how actually string store in java machine taqmcg@gmail.com - 2014-03-27 08:23 -0700
                      Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-27 11:50 -0400
                        Re: how actually string store in java machine taqmcg@gmail.com - 2014-03-28 06:58 -0700
                          Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-28 11:02 -0400
                            Re: how actually string store in java machine taqmcg@gmail.com - 2014-04-02 05:47 -0700
                              Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-04-02 10:15 -0400
                                Re: how actually string store in java machine taqmcg@gmail.com - 2014-04-03 08:58 -0700
              Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-26 17:07 -0700
        Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 16:07 -0400
          Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 16:16 -0400
            Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 16:19 -0400
              Re: how actually string store in java machine markspace <markspace@nospam.nospam> - 2014-03-25 14:00 -0700
                Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 17:21 -0400
                  Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-26 11:40 -0400
                    Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-26 17:46 -0700
    Re: how actually string store in java machine Lew <lewbloch@gmail.com> - 2014-03-25 15:07 -0700

Page 2 of 2 — ← Prev page 1 [2]

#27935

On 4/2/2014 8:47 AM, taqmcg@gmail.com wrote:
> On Friday, March 28, 2014 11:02:45 AM UTC-4, Eric Sosman wrote:
>> On 3/28/2014 9:58 AM, taqmcg@...
>>> On Thursday, March 27, 2014 11:50:22 AM UTC-4, Eric Sosman wrote:
>
>>       As I said, Java behaves more consistently across platforms than
>> other languages in my experience.  "Write Once, Run Anywhere" was a
>> goal of the language, but like "Don't Be Evil" it's not a goal that
>> was attained in perfection.  A few examples of variability:
>>
> ... examples delete ...
> Thanks Eric.  The first is pretty close to the situation with strings.  But it's interesting to note that these are all (I think) in the implementation of methods so that the documentation of these system dependencies is not in the language standard itself, but in the Javadocs for the standard library.  No methods are involved in the == comparison of strings, so if it were to be system dependent, then presumably that would have to be noted in the JLS itself.  Are there examples where the system dependencies are explicitly called out in the JLS, i.e., similar to allowing non-strict math results?

     I dunno.  In Original Java the == operator behaved the same way for
all reference types (it asked "Do these two references denote the same
instance?"), so the results of using == on two Integer references, for
example, could differ depending on how many values the particular JVM
chose to cache.  But then they changed the meaning of == for the
primitive wrappers, so that difference went away (and that's why I
mentioned using System.identityHashCode() in the comparison).

     It strikes me, though, that you seem to argue Java's platform
independence by progressively whittling away the dependencies that
arise. You began with "We'll just ignore strictfp" and "Oh, let's not
worry about anything involving the host environment," and now it seems
"Methods don't count, either."  With an approach like this, I might
well argue that all birds are crows: We'll just agree not to consider
peacocks, and emus don't fly so they scarcely count, and finches aren't
big enough to worry with, and ... eventually I'll have proved universal
crowhood!  ;-)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#27945

On Wednesday, April 2, 2014 10:15:22 AM UTC-4, Eric Sosman wrote:
> On 4/2/2014 8:47 AM, taqmcg@... wrote:
> 
>>itself.  Are there examples where the system dependencies are explicitly >>called out in the JLS, i.e., similar to allowing non-strict math results?
> 
> 
> 
>      I dunno.  In Original Java the == operator behaved the same way for 
> all reference types (it asked "Do these two references denote the same
> instance?"), so the results of using == on two Integer references, for
> example, could differ depending on how many values the particular JVM
> chose to cache.  But then they changed the meaning of == for the
> primitive wrappers, so that difference went away (and that's why I
> mentioned using System.identityHashCode() in the comparison).
> 
> 
>      It strikes me, though, that you seem to argue Java's platform
> independence by progressively whittling away the dependencies that
> arise. You began with "We'll just ignore strictfp" and "Oh, let's not
> worry about anything involving the host environment," and now it seems
> "Methods don't count, either."  With an approach like this, I might
> well argue that all birds are crows: We'll just agree not to consider
> peacocks, and emus don't fly so they scarcely count, and finches aren't
> big enough to worry with, and ... eventually I'll have proved universal
> crowhood!  ;-)
> 

Maybe!  I'm not trying to weasel out of this. I think it's useful to understand the limits of the WORM mantra.

Non-strict math is certainly an example where one is allowed to have system dependent results based solely upon the language of the current JLS.  But in terms of the design process for the language, that wasn't because they didn't want to eliminate that dependency.  Indeed the original spec precluded non-strict math.  It was only when they faced the issue that the spec was not feasibly implemented (in the sense that this requirement drastically affected floating point performance on most existing systems) that they changed the spec.  And even then they did not generally allow extended precision calculations, which would have potentially affected large numbers of results, but only calculations that used extended ranges in the exponents.

So I think a reasonable question that's not a "who is a real Scotsman?" is "Are there areas where the JLS itself allows a system dependency that was overlooked in the design of the language?"  Non-strict math wasn't overlooked.  It was explicitly added for feasibility.  A second question would be "What system dependencies are explicitly permitted by the JLS?" That would include non-strict math, at least for versions > 1.0.

With autoboxing one now has the same issue with constant Integers fields that we had with String (without involving any methods):

    class A
    public Integer xxx = 1111;
    end

    class B
    public Integer yyy = 1111;
    end

I hadn't checked but would have presumed we had a defined results for

    A.xxx == B.yyy

regardless of its magnitude.  

But that's not the case:  The actual language in the JLS that I see is (5.1.7):

>>>Start quote
If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.
<<<End quote

So somewhat to my surprise, the result is not well defined, but it's pretty clear that this is not an unconsidered system dependency, but a second case that the designers were fully cognizant of and explicitly decided to permit for expediency but were not especially happy about.

I'd be interested in understanding other areas in the JLS where either the language is unintentionally underspecified, or where there is an explicit deferral to the system.

     Regards,
     Tom McGlynn

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

#27883

On Wed, 26 Mar 2014 08:32:42 -0700, markspace
<markspace@nospam.nospam> wrote, quoted or indirectly quoted someone
who said :

>And certainly if you read a string from a file or the network, the VM 
>does not call String.intern() for you.  That would be silly.

1. It is a fairly substantial operation, like a HashMap put.
2. IIRC it suppresses GC.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates

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

#27862

On 03/25/2014 03:29 PM, Jan Burse wrote:
>
> If I remember well some of the newer JVM have reorganized
> their memory a little so as to avoid the limitations of
> the permanent store.
>
> http://openjdk.java.net/projects/jdk8/features#122
<http://java-performance.info/string-intern-in-java-6-7-8/>

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

#27863

On 03/25/2014 04:07 PM, Jeff Higgins wrote:
> On 03/25/2014 03:29 PM, Jan Burse wrote:
>>
>> If I remember well some of the newer JVM have reorganized
>> their memory a little so as to avoid the limitations of
>> the permanent store.
>>
>> http://openjdk.java.net/projects/jdk8/features#122
> <http://java-performance.info/string-intern-in-java-6-7-8/>
>
<http://java-performance.info/string-intern-java-7-8-part-3/#more-667>

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

#27864

On 03/25/2014 04:16 PM, Jeff Higgins wrote:
> <http://java-performance.info/string-intern-java-7-8-part-3/#more-667>
Oops.
<http://java-performance.info/string-intern-java-7-8-part-3>

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

#27865

On 3/25/2014 1:19 PM, Jeff Higgins wrote:
> On 03/25/2014 04:16 PM, Jeff Higgins wrote:
>> <http://java-performance.info/string-intern-java-7-8-part-3/#more-667>
> Oops.
> <http://java-performance.info/string-intern-java-7-8-part-3>
>
>


Quoted from your link:


"Summary

     "Despite serious optimizations done in the String.intern() 
implementation in Java 7+, it still takes a noticeable time to run 
(noticeable for CPU sensitive applications). The simple example in this 
article runs 3.5 times faster without calls to String.intern(). You 
should not use String.intern() as a safety net, passing every long 
living string into it. Instead process only fields with a limited number 
of possible distinct values (for example, states/provinces if processing 
addresses) - memory savings in this situation will definitely pay off 
the initial CPU costs of String.intern()."

* * *


Basically the "you should not use String.intern() ... passing every ... 
string into it."  Is the money shot.  If you have a string that's 
obviously repetitious (like a field for states or countries) it might be 
useful, other wise not so much.

Also, using String.intern() heavily requires that you increase memory 
available to it.


"The requirement to set -XX:StringTableSize=N JVM parameter in advance 
and dealing with its fixed value"


That alone would make me want to use a HashSet instead.

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

#27866

On 03/25/2014 05:00 PM, markspace wrote:
>
> Basically the "you should not use String.intern() ... passing every ...
> string into it."  Is the money shot.
>
I don't think there is anything new here.
But an interesting evolution to watch.

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

#27876

On 03/25/2014 05:21 PM, Jeff Higgins wrote:
> I don't think there is anything new here.

Well, we do now have a couple of java.lang.String.join() methods.
And a java.util.StringJoiner class.

Thanks to all for prompting me to look.

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

#27884

On Wed, 26 Mar 2014 11:40:47 -0400, Jeff Higgins
<jeff@invalid.invalid> wrote, quoted or indirectly quoted someone who
said :

>Well, we do now have a couple of java.lang.String.join() methods.
>And a java.util.StringJoiner class.

String message = String.join("-", "Java", "is", "cool");
     // message returned is: "Java-is-cool"

There is also a version that takes an Iterable.


The String "[George:Sally:Fred]" may be constructed as follows:


  StringJoiner sj = new StringJoiner( ":", "[", "]" );
  sj.add( "George" ).add( "Sally" ).add( "Fred" );
  String desiredString = sj.toString();

StringJoiner lives in java.util not java.lang like String.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates

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

#27867

Rishipal Singh wrote:
> i [sic] have read so many articles about how string store in java [sic] .
> but i have still problem 
> most of the sites says that the string is stored in run time constant pool memory .

Only interned strings are kept there.

> but how 
> please help me  explain in detail ...

<http://lmgtfy.com/?q=How+are+strings+stored+in+java>

-- 
Lew

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web