String reuse

Discussion in 'Java' started by Bob Rivers, Oct 19, 2004.

  1. Bob Rivers

    Bob Rivers Guest

    Hi,

    I was searching comp.lang.java and I didn't found a "definitive"
    answer about. Taking a looking into Java Glossaty, I found that:

    "Strings are immutable. Therefore they can be reused indefinitely, and
    they can be shared for many purposes. When you assign one String
    variable to another, no copy is made. Even when you take a substring
    there is no new String created. New Strings are created when: you
    concatentate. you do reads...." (I didn't understand "you do reads".
    Sorry my english).

    Ok, there is no doubt that when I concatenate strings (+=) java will
    generate a new object. But, if I only assign a new value to a String,
    will a new String be created?

    For example:

    String str = "Hi";
    str = "Hi Bob!";

    In the example above, how many strings I created?

    TIA,

    Bob - Brazil
    Bob Rivers, Oct 19, 2004
    #1
    1. Advertising

  2. Bob Rivers

    Eric Sosman Guest

    Bob Rivers wrote:
    > Hi,
    >
    > I was searching comp.lang.java and I didn't found a "definitive"
    > answer about. Taking a looking into Java Glossaty, I found that:
    >
    > "Strings are immutable. Therefore they can be reused indefinitely, and
    > they can be shared for many purposes. When you assign one String
    > variable to another, no copy is made. Even when you take a substring
    > there is no new String created. New Strings are created when: you
    > concatentate. you do reads...." (I didn't understand "you do reads".
    > Sorry my english).


    English is notoriously irregular and idiom-ridden,
    and I sometimes wonder how anyone can learn it -- Americans
    certainly do not! In this context "you do reads" is taken
    to mean

    you = you
    do = perform
    reads = input operations

    > Ok, there is no doubt that when I concatenate strings (+=) java will
    > generate a new object. But, if I only assign a new value to a String,
    > will a new String be created?
    >
    > For example:
    >
    > String str = "Hi";
    > str = "Hi Bob!";
    >
    > In the example above, how many strings I created?


    Two: one for "Hi" and one for "Hi Bob!" It is possible
    that these two Strings share some storage, so that there is
    only one 'H' and only one 'i' in the JVM's memory -- but
    there are two distinct String objects nonetheless.

    It is important to understand that str is not a String;
    it is a *reference* to a String. Here is another piece of
    code that uses two String objects, not four:

    String s1 = "Hi";
    String s2 = "Hi";
    String s3 = "Hi";
    String str = "Hi Bob!";

    The three distinct references s1,s2,s3 all refer to the same
    String object.

    --

    (One of those illiterate Americans ...)
    Eric Sosman, Oct 19, 2004
    #2
    1. Advertising

  3. Java creates a String constant pool where all String literals live. So, in you
    example, there would be two Strings literals living in the pool: "Hi" and "Hi
    Bob!". Your programs has one String instance, str, and it would start by
    pointing at "Hi" but then is changed to point to "Hi Bob!". So, to answer the
    question: There is one String instance and two String literals.

    Why have a String literal pool? Often String literals end up being longer than
    just a few bytes. Keeping a single copy saves heap space by not needleesly
    duplicating the String literal. Also the program can be faster as it doesn't
    need to copy literals when they are assigned.

    For example:
    byte[] chars = new byte[10240];
    Arrays.fill( chars, 'A' );
    String longString = new String( chars );
    String anotherInstance = longString;
    String yetAnotherInstance = anotherInstance;

    This example creates a 10K String literal with 3 String instances pointing to
    is. If each instance got its own copy of the literal then lots of memory would
    be wasted.

    In article <>, Bob Rivers wrote:
    > Hi,
    >
    > I was searching comp.lang.java and I didn't found a "definitive"
    > answer about. Taking a looking into Java Glossaty, I found that:
    >
    > "Strings are immutable. Therefore they can be reused indefinitely, and
    > they can be shared for many purposes. When you assign one String
    > variable to another, no copy is made. Even when you take a substring
    > there is no new String created. New Strings are created when: you
    > concatentate. you do reads...." (I didn't understand "you do reads".
    > Sorry my english).
    >
    > Ok, there is no doubt that when I concatenate strings (+=) java will
    > generate a new object. But, if I only assign a new value to a String,
    > will a new String be created?
    >
    > For example:
    >
    > String str = "Hi";
    > str = "Hi Bob!";
    >
    > In the example above, how many strings I created?
    >
    > TIA,
    >
    > Bob - Brazil



    --

    SDF Public Access UNIX System - http://sdf.lonestar.org
    Matt SDF Smith, Oct 19, 2004
    #3
  4. Bob Rivers <> scribbled the following:
    > Hi,


    > I was searching comp.lang.java and I didn't found a "definitive"
    > answer about. Taking a looking into Java Glossaty, I found that:


    > "Strings are immutable. Therefore they can be reused indefinitely, and
    > they can be shared for many purposes. When you assign one String
    > variable to another, no copy is made. Even when you take a substring
    > there is no new String created. New Strings are created when: you
    > concatentate. you do reads...." (I didn't understand "you do reads".
    > Sorry my english).


    > Ok, there is no doubt that when I concatenate strings (+=) java will
    > generate a new object. But, if I only assign a new value to a String,
    > will a new String be created?


    > For example:


    > String str = "Hi";
    > str = "Hi Bob!";
    >
    > In the example above, how many strings I created?


    Usually, two. In the general case, assigning a variable to refer to
    another object has nothing whatsoever to do with the object the
    variable previously referred to.
    This is usually the case with Strings, too. If we modify your code
    slightly:

    String str = "Hi";
    str = "Bob!";

    then the answer I have given above applies fully. However, in your
    original code, the string "Hi" is a substring of the string "Hi Bob!"
    so the compiler might optimise the code to reuse a portion of the same
    character storage. None of this optimisation has any effects visible to
    your code, though - it happens entirely within the JVM.
    Note also that when you assign a variable to refer to another object,
    the previously referred object becomes eligible for garbage collection,
    if its reference chains to any currently live threads become broken.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-------------------------------------------------------- rules! --------/
    "'I' is the most beautiful word in the world."
    - John Nordberg
    Joona I Palaste, Oct 19, 2004
    #4
  5. Bob Rivers schrieb:
    > Hi,
    >
    > I was searching comp.lang.java and I didn't found a "definitive"
    > answer about. Taking a looking into Java Glossaty, I found that:
    >
    > "Strings are immutable. Therefore they can be reused indefinitely, and
    > they can be shared for many purposes. When you assign one String
    > variable to another, no copy is made. Even when you take a substring
    > there is no new String created. New Strings are created when: you
    > concatentate. you do reads...." (I didn't understand "you do reads".
    > Sorry my english).
    >
    > Ok, there is no doubt that when I concatenate strings (+=) java will
    > generate a new object. But, if I only assign a new value to a String,
    > will a new String be created?
    >
    > For example:
    >
    > String str = "Hi";
    > str = "Hi Bob!";
    >
    > In the example above, how many strings I created?


    You created 2 string objects: "Hi" and "Hi Bob!". And the end the
    variable str references the object "Hi". The object "Hi Bob!" is no
    longer referenced anywhere (and hence it will be garbage-collected some
    time later).
    Note the subtle distinction between variables (referencing an object)
    and the objects themselves.
    >
    > TIA,
    >
    > Bob - Brazil



    --
    "Thomas:Fritsch$ops:de".replace(':','.').replace('$','@')
    Thomas Fritsch, Oct 19, 2004
    #5
  6. Thomas Fritsch <> scribbled the following:
    > Bob Rivers schrieb:
    >> Hi,
    >>
    >> I was searching comp.lang.java and I didn't found a "definitive"
    >> answer about. Taking a looking into Java Glossaty, I found that:
    >>
    >> "Strings are immutable. Therefore they can be reused indefinitely, and
    >> they can be shared for many purposes. When you assign one String
    >> variable to another, no copy is made. Even when you take a substring
    >> there is no new String created. New Strings are created when: you
    >> concatentate. you do reads...." (I didn't understand "you do reads".
    >> Sorry my english).
    >>
    >> Ok, there is no doubt that when I concatenate strings (+=) java will
    >> generate a new object. But, if I only assign a new value to a String,
    >> will a new String be created?
    >>
    >> For example:
    >>
    >> String str = "Hi";
    >> str = "Hi Bob!";
    >>
    >> In the example above, how many strings I created?


    > You created 2 string objects: "Hi" and "Hi Bob!". And the end the
    > variable str references the object "Hi". The object "Hi Bob!" is no
    > longer referenced anywhere (and hence it will be garbage-collected some
    > time later).


    You got these two backwards.

    > Note the subtle distinction between variables (referencing an object)
    > and the objects themselves.


    --
    /-- Joona Palaste () ------------- Finland --------\
    \-------------------------------------------------------- rules! --------/
    "You will be given the plague."
    - Montgomery Burns
    Joona I Palaste, Oct 19, 2004
    #6
  7. Thomas Fritsch wrote:
    > Bob Rivers schrieb:
    >
    >> ...
    >> String str = "Hi";
    >> str = "Hi Bob!";
    >>
    >> In the example above, how many strings I created?

    >
    >
    > You created 2 string objects: "Hi" and "Hi Bob!". And the end the
    > variable str references the object "Hi". The object "Hi Bob!" is no

    Stupid me! It is the other way round, of course!
    > longer referenced anywhere (and hence it will be garbage-collected some
    > time later).
    > Note the subtle distinction between variables (referencing an object)
    > and the objects themselves.
    > ...


    --
    "Thomas:Fritsch$ops:de".replace(':','.').replace('$','@')
    Thomas Fritsch, Oct 19, 2004
    #7
  8. Bob Rivers

    Oscar kind Guest

    Bob Rivers <> wrote:
    > String str = "Hi";
    > str = "Hi Bob!";
    >
    > In the example above, how many strings I created?


    Two String Objects, and one reference to a String.


    --
    Oscar Kind http://home.hccnet.nl/okind/
    Software Developer for contact information, see website

    PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
    Oscar kind, Oct 19, 2004
    #8
  9. Matt SDF Smith <> writes:

    > Java creates a String constant pool where all String literals live.
    > So, in you example, there would be two Strings literals living in
    > the pool: "Hi" and "Hi Bob!".


    Correct. Completely technical, String *literals* is a concept of Java
    source code. When compiled, they generate entries in the constant
    pool and code for generating a String instance from such a constant.

    > Your programs has one String instance, str, and it would start by
    > pointing at "Hi" but then is changed to point to "Hi Bob!".


    "str" is not a String instance. It is a variable of type String.
    It does point to different instances of the String class at different
    points of the execution.

    > So, to answer the question: There is one String
    > instance and two String literals.


    There are two String literals. A string literal is a source expression
    of type String, so it evaluates to a String instance. Since the two
    literals are different, the String instances are also different, so
    there are *two* String instances (referred to in turn by *one* String
    variable).

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Oct 19, 2004
    #9
  10. Bob Rivers

    Will Hartung Guest

    "Matt SDF Smith" <> wrote in message
    news:...
    > Why have a String literal pool? Often String literals end up being longer

    than
    > just a few bytes. Keeping a single copy saves heap space by not

    needleesly
    > duplicating the String literal. Also the program can be faster as it

    doesn't
    > need to copy literals when they are assigned.
    >
    > For example:
    > byte[] chars = new byte[10240];
    > Arrays.fill( chars, 'A' );
    > String longString = new String( chars );
    > String anotherInstance = longString;
    > String yetAnotherInstance = anotherInstance;
    >
    > This example creates a 10K String literal with 3 String instances pointing

    to
    > is. If each instance got its own copy of the literal then lots of memory

    would
    > be wasted.


    At runtime, there is a different behavior.

    As the original post mentioned "when strings are read", which means that
    when you get data from a file, or a database, or whatever, all of the
    strings that it creates are brand new, even if you've seen them before.

    For example, if I have a file with 5 lines:
    1234567890
    1234567890
    1234567890
    1234567890
    1234567890

    And I do a BufferedReader#readLine() from that file, I will get 5 new
    strings, that while are all .equals, will in fact have their own storage,
    and therefore will not be == (i.e. the same object).

    The String class, however, has a rarely used method named "intern", which
    will make the effort to make .equals Strings actually ==.

    So, I could do this (given the contrived file above):
    String s1, s2;

    s1 = br.readLine();
    s2 = br.readLine();

    boolean f = s1 == s2; // False;

    s1 = s1.intern();
    s2 = s2.intern();

    f = s1 == s2; // True.

    This can come into play if you're loading, say, a large XML document as an
    example. There are a lot of common tags in an XML document, and if you take
    the effort to actually intern the tag names, you'll save memory overall. If
    I load 100 <text>Some text</text> tags, then by interning the tags as they
    are read will free the other 99 new "test" tag Strings. For all I know, the
    XML parsers DO do this (it's more important in a DOM situation, than
    something like SAX), I don't know, but it's a simple example where you can
    easily benefit from taking this extra step, and if Strings were not
    immutable, you'd not be able to take advantage of something like this.

    Regards,

    Will Hartung
    ()
    Will Hartung, Oct 19, 2004
    #10
  11. Bob Rivers

    steph Guest

    Le 19/10/2004 19:14, Matt SDF Smith a &eacute;crit :

    > Java creates a String constant pool where all String literals live. So, in you
    > example, there would be two Strings literals living in the pool: "Hi" and "Hi
    > Bob!". Your programs has one String instance, str, and it would start by
    > pointing at "Hi" but then is changed to point to "Hi Bob!". So, to answer the
    > question: There is one String instance and two String literals.
    >
    > Why have a String literal pool? Often String literals end up being longer than
    > just a few bytes. Keeping a single copy saves heap space by not needleesly
    > duplicating the String literal. Also the program can be faster as it doesn't
    > need to copy literals when they are assigned.
    >
    > For example:
    > byte[] chars = new byte[10240];
    > Arrays.fill( chars, 'A' );
    > String longString = new String( chars );
    > String anotherInstance = longString;
    > String yetAnotherInstance = anotherInstance;
    >
    > This example creates a 10K String literal with 3 String instances pointing to
    > is. If each instance got its own copy of the literal then lots of memory would
    > be wasted.
    >


    For me, it's not realy true.
    This code will consume 20k of heap memory, because "new String(chars)" will
    duplicate the array of characters.
    Indeed, because you can do
    byte[] chars = new byte[10240];
    Arrays.fill( chars, 'A' );
    String longString = new String( chars );
    chars[334]='B';
    and because strings are imutable, the constructor has to duplicate the data.

    > In article <>, Bob Rivers wrote:
    >
    >>Hi,
    >>
    >>I was searching comp.lang.java and I didn't found a "definitive"
    >>answer about. Taking a looking into Java Glossaty, I found that:
    >>
    >>"Strings are immutable. Therefore they can be reused indefinitely, and
    >>they can be shared for many purposes. When you assign one String
    >>variable to another, no copy is made. Even when you take a substring
    >>there is no new String created. New Strings are created when: you
    >>concatentate. you do reads...." (I didn't understand "you do reads".
    >>Sorry my english).
    >>
    >>Ok, there is no doubt that when I concatenate strings (+=) java will
    >>generate a new object. But, if I only assign a new value to a String,
    >>will a new String be created?
    >>
    >>For example:
    >>
    >>String str = "Hi";
    >>str = "Hi Bob!";
    >>
    >>In the example above, how many strings I created?
    >>
    >>TIA,
    >>
    >>Bob - Brazil

    >
    >
    >


    --
    stephane
    retirez les lettres majuscules et le 666 de l'adresse pour l'utiliser.
    steph, Oct 20, 2004
    #11
  12. You are correct in stating that 20K will be used. 10K by the byte array and
    10K by the Strings. However, the question being asked was how much memory was
    being eaten by the Strings. The byte array was an example of creating a large
    String. Also, as you pointed out, changing the byte array does not affect the
    Strings in any way.


    In article <41763085$0$27913$>, steph wrote:
    > Le 19/10/2004 19:14, Matt SDF Smith a &eacute;crit :
    >

    <snip>

    >
    > For me, it's not realy true.
    > This code will consume 20k of heap memory, because "new String(chars)" will
    > duplicate the array of characters.
    > Indeed, because you can do
    > byte[] chars = new byte[10240];
    > Arrays.fill( chars, 'A' );
    > String longString = new String( chars );
    > chars[334]='B';
    > and because strings are imutable, the constructor has to duplicate the data.
    >



    --
    SDF Public Access UNIX System - http://sdf.lonestar.org
    Matt SDF Smith, Oct 20, 2004
    #12
  13. Bob Rivers

    Tony Morris Guest

    "Matt SDF Smith" <> wrote in message
    news:...
    > Java creates a String constant pool where all String literals live.


    This comment is potentially misleading.
    The concept of a "String literal pool" is in fact a very abstract one, that
    should be used only to understand how String compile-time constants (JLS 2e
    15.28) are handled at runtime. That is, there is no 'actual pool'.

    To demonstrate this point, consider the following:

    class X
    {
    void m()
    {
    {
    String s = "s";
    }

    {
    String s = "s";
    }
    }
    }

    How many String objects exist during the execution of m()?
    Most of you will say 1, but this is not true.
    Good luck.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
    Tony Morris, Oct 21, 2004
    #13
  14. Bob Rivers

    Yogo Guest

    "Tony Morris" wrote

    > class X
    > {
    > void m()
    > {
    > {
    > String s = "s";
    > }
    >
    > {
    > String s = "s";
    > }
    > }
    > }
    >
    > How many String objects exist during the execution of m()?
    > Most of you will say 1, but this is not true.


    Hmm, I think there is only 1 String object. I tried the following and both
    references point to the same String object ("One String object" is
    displayed).

    public class StringPool {
    public static void main (String s[]){
    new X().m();
    }
    }

    class X {
    void m() {
    RefObject o1=null, o2=null;
    {
    String s = "s";
    o1=new RefObject(s);
    }
    {
    String s = "s";
    o2=new RefObject(s);
    }
    if (o1.equals(o2))
    System.out.println("One String object");
    else
    System.out.println("Two String objects");
    }
    }

    class RefObject {
    String ref;
    RefObject (String ref){
    this.ref=ref;
    }
    public boolean equals(RefObject obj){
    return (this.ref == obj.ref);
    }
    }


    Yogo
    Yogo, Oct 21, 2004
    #14
  15. Bob Rivers

    Tony Morris Guest

    "Yogo" <n o s p a m> wrote in message
    news:41779bdb$0$14941$4all.nl...
    > "Tony Morris" wrote
    >
    > > class X
    > > {
    > > void m()
    > > {
    > > {
    > > String s = "s";
    > > }
    > >
    > > {
    > > String s = "s";
    > > }
    > > }
    > > }
    > >
    > > How many String objects exist during the execution of m()?
    > > Most of you will say 1, but this is not true.

    >
    > Hmm, I think there is only 1 String object. I tried the following and both
    > references point to the same String object ("One String object" is
    > displayed).
    >
    > public class StringPool {
    > public static void main (String s[]){
    > new X().m();
    > }
    > }
    >
    > class X {
    > void m() {
    > RefObject o1=null, o2=null;
    > {
    > String s = "s";
    > o1=new RefObject(s);
    > }
    > {
    > String s = "s";
    > o2=new RefObject(s);
    > }
    > if (o1.equals(o2))
    > System.out.println("One String object");
    > else
    > System.out.println("Two String objects");
    > }
    > }
    >
    > class RefObject {
    > String ref;
    > RefObject (String ref){
    > this.ref=ref;
    > }
    > public boolean equals(RefObject obj){
    > return (this.ref == obj.ref);
    > }
    > }
    >
    >
    > Yogo
    >
    >


    Yes - in your case, you are right - there is only one instance (I only
    skimmed it, but I noticed you held references).
    However, note that your code and my code differ substantially.

    Here's the catch: prove that my code can quite potentially use 2 String
    instances.
    Or better, prove that a String literal is not necessarily the same instance
    throughout the execution of a VM (despite JLS 2e 3.20.5 which is ambiguous).

    It can be done.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
    Tony Morris, Oct 21, 2004
    #15
  16. Tony Morris wrote:
    >
    > "Matt SDF Smith" <> wrote in message
    > news:..
    > > Java creates a String constant pool where all String literals live.

    >
    > This comment is potentially misleading.
    > The concept of a "String literal pool" is in fact a very abstract one, that
    > should be used only to understand how String compile-time constants (JLS 2e
    > 15.28) are handled at runtime. That is, there is no 'actual pool'.


    Why do you say that? java.lang.String#intern() states that it uses the pool (of unique
    strings.)

    --
    Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
    ==============================================================
    * The Ultimate DBMS is here!
    * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
    Lee Fesperman, Oct 22, 2004
    #16
  17. Lee Fesperman wrote:

    > Tony Morris wrote:
    >
    >>"Matt SDF Smith" <> wrote in message
    >>news:..
    >>
    >>>Java creates a String constant pool where all String literals live.

    >>
    >>This comment is potentially misleading.
    >>The concept of a "String literal pool" is in fact a very abstract one, that
    >>should be used only to understand how String compile-time constants (JLS 2e
    >>15.28) are handled at runtime. That is, there is no 'actual pool'.

    >
    >
    > Why do you say that? java.lang.String#intern() states that it uses the pool (of unique
    > strings.)


    The class String maintains a pool of unique Strings, to which
    String.intern() method may add a String when invoked. References to
    compile-time constant Strings are guaranteed to refer to an interned
    String. However, as I was recently made aware, otherwise unreferenced
    String instances can be GC'd from the intern pool ("can" in the sense
    that recent Sun JVMs can be observed to do so), so it is not in general
    safe to assume that the String instance representing a particular
    compile-time constant String at one point in your program's execution
    is the same instance that represents the same or an equal String at some
    other point in your program's execution. Whether this is a reasonable
    behavior is subject to debate, but the fact that Sun's own JVM exhibits
    it makes the question rather moot.


    John Bollinger
    John C. Bollinger, Oct 22, 2004
    #17
  18. John C. Bollinger wrote:
    >
    > Lee Fesperman wrote:
    >
    > > Tony Morris wrote:
    > >
    > >>The concept of a "String literal pool" is in fact a very abstract one, that
    > >>should be used only to understand how String compile-time constants (JLS 2e
    > >>15.28) are handled at runtime. That is, there is no 'actual pool'.

    > >
    > > Why do you say that? java.lang.String#intern() states that it uses the pool
    > > (of unique strings.)

    >
    > The class String maintains a pool of unique Strings, to which
    > String.intern() method may add a String when invoked. References to
    > compile-time constant Strings are guaranteed to refer to an interned
    > String. However, as I was recently made aware, otherwise unreferenced
    > String instances can be GC'd from the intern pool ("can" in the sense
    > that recent Sun JVMs can be observed to do so), so it is not in general
    > safe to assume that the String instance representing a particular
    > compile-time constant String at one point in your program's execution
    > is the same instance that represents the same or an equal String at some
    > other point in your program's execution. Whether this is a reasonable
    > behavior is subject to debate, but the fact that Sun's own JVM exhibits
    > it makes the question rather moot.


    Of course, my article was just to point out to Tony that the pool does exist. However,
    you bring up a good issue for discussion. I had assumed that the string pool never
    shrunk.

    Thinking about it, it seems to be a good optimization for the JVM to make. Generally, an
    application couldn't even tell that unreferenced strings were dropped from the pool. The
    only ways to detect it would be to use WeakReference's, etc. or to retain the
    identityHashCode for an intern'ed string for later checking. The latter is not
    guaranteed to work, though.

    --
    Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
    ==============================================================
    * The Ultimate DBMS is here!
    * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
    Lee Fesperman, Oct 25, 2004
    #18
  19. Lee Fesperman wrote:

    > John C. Bollinger wrote:


    >>The class String maintains a pool of unique Strings, to which
    >>String.intern() method may add a String when invoked. References to
    >>compile-time constant Strings are guaranteed to refer to an interned
    >>String. However, as I was recently made aware, otherwise unreferenced
    >>String instances can be GC'd from the intern pool ("can" in the sense
    >>that recent Sun JVMs can be observed to do so), so it is not in general
    >>safe to assume that the String instance representing a particular
    >>compile-time constant String at one point in your program's execution
    >>is the same instance that represents the same or an equal String at some
    >>other point in your program's execution. Whether this is a reasonable
    >>behavior is subject to debate, but the fact that Sun's own JVM exhibits
    >>it makes the question rather moot.

    >
    >
    > Of course, my article was just to point out to Tony that the pool does exist. However,
    > you bring up a good issue for discussion. I had assumed that the string pool never
    > shrunk.
    >
    > Thinking about it, it seems to be a good optimization for the JVM to make. Generally, an
    > application couldn't even tell that unreferenced strings were dropped from the pool. The
    > only ways to detect it would be to use WeakReference's, etc. or to retain the
    > identityHashCode for an intern'ed string for later checking. The latter is not
    > guaranteed to work, though.


    FWIW, The test code I have seen that demonstrates the Sun VM behavior in
    fact uses the identityHashCode technique.

    I was surprised, too, to find that interned Strings were being GCd. My
    initial reading of the JLS led me to think that they would not be GC'd,
    but the behavior does not seem to be forbidden. As it takes rather
    extraordinary means to detect the situation, I'm not loosing any sleep
    over it.


    John Bollinger
    John C. Bollinger, Oct 25, 2004
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    1
    Views:
    473
  2. tshad
    Replies:
    5
    Views:
    514
    Steve C. Orr [MVP, MCSD]
    May 17, 2005
  3. Hylander

    To reuse or not to reuse....

    Hylander, Feb 26, 2004, in forum: Java
    Replies:
    0
    Views:
    410
    Hylander
    Feb 26, 2004
  4. code reuse and design reuse

    , Feb 7, 2006, in forum: C Programming
    Replies:
    16
    Views:
    1,000
    Malcolm
    Feb 12, 2006
  5. jacob navia

    To reuse or not to reuse

    jacob navia, Nov 5, 2006, in forum: C Programming
    Replies:
    19
    Views:
    512
    Dave Thompson
    Dec 18, 2006
Loading...

Share This Page