• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

String pooling and garbage collector

 
Ranch Hand
Posts: 692
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i know the answer but i just want to clarify
with this

there are 2 String object on heap
1 which has just naved and
2nd which has NAVED , right

but just one Object which has NAVED is refered by reference var called str
and other Object is eligible for gc ,
right ?
 
Rancher
Posts: 3742
16
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

naved momin wrote:and other Object is eligible for gc


No. The other object is referenced from the string pool (because it is a String literal) and so will not be GCed
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"naved" isn't stored on the heap but in the String constant pool.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:"naved" isn't stored on the heap but in the String constant pool.


Corey McGlone wouldn't agree with you on that.

What is the String Literal Pool? ... it's a collection of references to String objects. Strings, even though they are immutable, are still objects like any other in Java. Objects are created on the heap and Strings are no exception. So, Strings that are part of the "String Literal Pool" still live on the heap, but they have references to them from the String Literal Pool.



 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joanne Neal wrote:

Rob Spoor wrote:"naved" isn't stored on the heap but in the String constant pool.


Corey McGlone wouldn't agree with you on that.

What is the String Literal Pool? ... it's a collection of references to String objects. Strings, even though they are immutable, are still objects like any other in Java. Objects are created on the heap and Strings are no exception. So, Strings that are part of the "String Literal Pool" still live on the heap, but they have references to them from the String Literal Pool.





Well, if you want to get picky, according to the JVM spec, "Each runtime constant pool is allocated from the Java virtual machine's method area," and "Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. ..."

The part about "living on the heap but having references from the String Literal Pool" is not consistent with the spec.

So, yes, all Strings are on the heap, but some are in a special area of the heap known as the constant pool, but no, there's no reference "from the pool to the heap".
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joanne Neal wrote:

naved momin wrote:and other Object is eligible for gc


No. The other object is referenced from the string pool (because it is a String literal) and so will not be GCed



@naved: Your thinking was correct in general, but in this particular case, your original String came from a literal in your source code, and so was stored in the constant pool as Joanne indicates and is therefore not eligible for GC. If, however, you had gotten that original String somewhere else, say by reading it from a file, then it would not be in the constant pool, and your logic that it would be eligible for GC would be correct.

I hope that's clear!
 
Ranch Hand
Posts: 112
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, just to make sure, that means that the string "naved" is stored in the string constant pool. And toUpperCase() method creates a new string object. So, we have two objects essentially. Is this correct?

Thanks,
Pavan.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pavan Kumar Dittakavi wrote:So, just to make sure, that means that the string "naved" is stored in the string constant pool.



Yes, because it's a String literal in the source code.

And toUpperCase() method creates a new string object.



Yes, always, regardless of whether the original was in the constant pool or not, and regardless of whether or not there's a String equal to the result already in the constant pool.

So, we have two objects essentially. Is this correct?



Yes, "naved", which is in the constant pool, and "NAVED", which is not.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeff Verdegan wrote:Yes, always


One small exception - if the string is already all uppercase, the original string is returned.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joanne Neal wrote:

Jeff Verdegan wrote:Yes, always


One small exception - if the string is already all uppercase, the original string is returned.



Right. Thanks for the correction.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's true for all String methods that return other Strings. Even replaceFirst, replaceAll and replace(CharSequence, CharSequence), which use java.util.regex.Pattern in the background, will in the end return themselves if the pattern did not lead to any matches.
 
naved momin
Ranch Hand
Posts: 692
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeff Verdegan wrote:

Pavan Kumar Dittakavi wrote:So, just to make sure, that means that the string "naved" is stored in the string constant pool.



Yes, because it's a String literal in the source code.

And toUpperCase() method creates a new string object.



Yes, always, regardless of whether the original was in the constant pool or not, and regardless of whether or not there's a String equal to the result already in the constant pool.

So, we have two objects essentially. Is this correct?



Yes, "naved", which is in the constant pool, and "NAVED", which is not.


thanks jeff, lets revise everything
  • String literals are stored on string constant pool //this cannot be gced since they are not in the heap, ok ?
  • String object that we get after envoking any of String's methods are stored in heap
  • when the String literal is exactly same as the returning String object then the literal from the constant pool is returned,
    so no new object is created in this case right ?
  •  
    Jeff Verdegan
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    naved momin wrote:

    Jeff Verdegan wrote:

    Pavan Kumar Dittakavi wrote:So, just to make sure, that means that the string "naved" is stored in the string constant pool.



    Yes, because it's a String literal in the source code.

    And toUpperCase() method creates a new string object.



    Yes, always, regardless of whether the original was in the constant pool or not, and regardless of whether or not there's a String equal to the result already in the constant pool.

    So, we have two objects essentially. Is this correct?



    Yes, "naved", which is in the constant pool, and "NAVED", which is not.


    thanks jeff, lets revise everything
    String literals are stored on string constant pool



    Correct.

    //this cannot be gced since they are not in the heap, ok ?



    According to the JVM spec: "Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it."

    The constant pool is part of the method area, which is logically part of the heap, and individual implementations may choose to GC or not GC it.

  • String object that we get after envoking any of String's methods are stored in heap


  • All objects are always stored in the heap. (Except that there's been talk of allowing stack storage for objects that don't leak out of the method that created them. I don't know if it's been implemented yet.)

  • when the String literal is exactly same as the returning String object then the literal from the constant pool is returned,
    so no new object is created in this case right ?


  • String literals have nothing to do with it. It's when the result of calling a method is a String that is equal() to the original, then no new String is created. So, for instance, "naved".toUpperCase() will create a new String object and return a reference to it, whereas "NAVED".toUpperCase() will simply return a reference to the original "NAVED" String. Note that this is true whether the original is a literal or not, and whether it is stored in the constant pool or not.

    So:

    1. There's a constant pool.

    2. It's a special part of the heap.

    3. It may or may not be GCed, and you really never need to worry about whether it is or not.

    4. Any String literal in your source code, such as "naved", is stored in the constant pool.

    5. Any time you call intern() on a String, a new entry is put into the constant pool, if there's not one already there that is equal() to the original.

    6. The JVM stores certain Strings in the constant pool, such as class names and method names. This is not something you need to be concerned about when writing Java code.

    7. When the result of a String method would be equal() to the original String, there is no new String object created; it simply returns a reference to the original (that is to itself). This is completely independent of the constant pool and has nothing to do with the constant pool.
     
    naved momin
    Ranch Hand
    Posts: 692
    Eclipse IDE Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Jeff Verdegan wrote:

    naved momin wrote:

    Jeff Verdegan wrote:

    Pavan Kumar Dittakavi wrote:So, just to make sure, that means that the string "naved" is stored in the string constant pool.



    Yes, because it's a String literal in the source code.

    And toUpperCase() method creates a new string object.



    Yes, always, regardless of whether the original was in the constant pool or not, and regardless of whether or not there's a String equal to the result already in the constant pool.

    So, we have two objects essentially. Is this correct?



    Yes, "naved", which is in the constant pool, and "NAVED", which is not.


    thanks jeff, lets revise everything
    String literals are stored on string constant pool



    Correct.

    //this cannot be gced since they are not in the heap, ok ?



    According to the JVM spec: "Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it."

    The constant pool is part of the method area, which is logically part of the heap, and individual implementations may choose to GC or not GC it.

  • String object that we get after envoking any of String's methods are stored in heap


  • All objects are always stored in the heap. (Except that there's been talk of allowing stack storage for objects that don't leak out of the method that created them. I don't know if it's been implemented yet.)

  • when the String literal is exactly same as the returning String object then the literal from the constant pool is returned,
    so no new object is created in this case right ?


  • String literals have nothing to do with it. It's when the result of calling a method is a String that is equal() to the original, then no new String is created. So, for instance, "naved".toUpperCase() will create a new String object and return a reference to it, whereas "NAVED".toUpperCase() will simply return a reference to the original "NAVED" String. Note that this is true whether the original is a literal or not, and whether it is stored in the constant pool or not.

    So:

    1. There's a constant pool.

    2. It's a special part of the heap.

    3. It may or may not be GCed, and you really never need to worry about whether it is or not.

    4. Any String literal in your source code, such as "naved", is stored in the constant pool.

    5. Any time you call intern() on a String, a new entry is put into the constant pool, if there's not one already there that is equal() to the original.

    6. The JVM stores certain Strings in the constant pool, such as class names and method names. This is not something you need to be concerned about when writing Java code.

    7. When the result of a String method would be equal() to the original String, there is no new String object created; it simply returns a reference to the original (that is to itself). This is completely independent of the constant pool and has nothing to do with the constant pool.


    thanks for this jeff. .
     
    reply
      Bookmark Topic Watch Topic
    • New Topic