• 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 Literals and Garbage Collection.

 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have heard from several sources that String literals are not eligible for Garbage Collection. This implies that if you create enough string literals, you will eventually kill the JVM as you will run out of memory.
This doesn�t sound correct.
Does anybody know on what grounds these assumptions have been made. Also, can anybody quote any references that discuss this topic in more detail. I have seen nothing to support these claims in the JLS.
 
Ranch Hand
Posts: 464
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe String literals are eligible for GC..
They are String objects actually. Just that they are created in the compile time and reused, to preserve the memeory resources.
String r = "Java"; //Compile time
String r = new String ("Java"); //runtime
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I heard it also that string literals not gc'd.
 
Ranch Hand
Posts: 782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

They are String objects actually. Just that they are created in the compile time...


Objects in Java is created at runtime!
Bye.
Viki.
------------------
Count the flowers of ur garden,NOT the leafs which falls away!

[This message has been edited by Vikrama Sanjeeva (edited November 08, 2001).]
 
Rosie Nelson
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is what I assumed, but an explanation on JQ plus states that string literals (once thay are no longer referenced) are not eligible for garbage collection. I also heard it from one of the moderators on this site, although nobody can seem to back it up with documentary evidence/references.
[This message has been edited by Rosie Nelson (edited November 08, 2001).]
 
Ranch Hand
Posts: 182
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
In all the places it is written that String literals are not GC.
OK,
but why this code doesn't crash the system. There is no extra-memory taken, everything seems to be OK.
public class TestLiterals
{
public static void main(String args[])
{
for(int i=0;;i++)
{
/*String s = "around 47000characters, I put wwwwwwww of 47000 times" + i; i for being sure that there will be different charaters*/
String a= s.concat(s).concat(s).concat(s).concat(s);
System.out.println("created " + i + "literal strings" );
}
}
}

..Cristian
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Found the problem interesting so did a bit of research.
As far as I am aware how Garbage Collection works is not defined in either the Java Language or Virtual Machine specifications, only that it occurs. Not much help there.
String literals are just String objects (JLS 3.10.5). Therefore would assume same rules for GC apply in that they do get GC.
What is in the specification is that different literal references use the same string.
For example
String x="literal";
String y="literal";
x and y actualy only reference one String instance. Can do this because of the immutability of Strings. Therefore if you released x the reference y would still exist and it would not be available for gc.
Now to manage this feat of always using the same String an intern method on String is used. To achieve this functionality would seem reasonable to imply a reference must exist so can then set a variable to the literal value - Javadocs mention an internal pool of strings. Therefore there is always a reference and so they cannot be GC. However argument is inconclusive as intern is a native method.
No definite answers, sorry. I would be grateful if anybody knows the answer.
Phil
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When a class is loaded, before any instances of it are created, a "classfile" is created by the classloader in an area separate from the heap.

In this classfile is a Constant Pool that holds final variable constants etc. Part of the Constant Pool is the String literal table, which hold references to the String Pool where the string is kept.


4.4.3 The CONSTANT_String_info Structure

The CONSTANT_String_info structure is used to represent constant objects of the type String:
CONSTANT_String_info {
u1 tag;
u2 string_index;
}
The items of the CONSTANT_String_info structure are as follows:
tag
The tag item of the CONSTANT_String_info structure has the value CONSTANT_String (8).
string_index
The value of the string_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Utf8_info (�4.4.7) structure representing the sequence of characters to which the String object is to be initialized.


Since classes that are loaded by the bootstrap classloader (the regular one) are NEVER unloaded, once a string is created as a literal or interned, and therefore built into the String Pool, they never go away.
However, since this was done as a means of optimizing the use of Strings (so that the same string value can be used multiple times instead of creating a new object each time) unless you have an unbelievably large number of unique strings, you will not have a problem. Also the String Pool is (usually) kept in an area of memory reserved for the JVM and does not use any of the space allocated for the heap - so it does not use up room for other objects.
Of course if you use the "new" operator you bypass the String Pool and create an object on the heap anyway.
------------------
Cindy Glass
Sun Certified Programmer for the Java� 2 Platform
Co-author of Java 2 Certification Passport
[This message has been edited by Cindy Glass (edited November 08, 2001).]
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here there is program that shows how String literals are not g.c.ed
http://www.javaranch.com/ubb/Forum24/HTML/012708.html
The constant pool of a class file doesn't hold a "String literal pool" because the JVMS does'nt mention it at all.
The constant pool holds entries of the type CONSTANT_String_info and CONSTANT_Utf8_info to describe the content of String literals (among others things) ,but these entries are not String objects. These entries just represent the content of the String object that will be created when the entry is resolved by the JVM.
Resolving an entry in the constant pool means to replace the symbolic reference (made up of names) with the address of the object in memory.
All objects are created in the heap and they must include a pointer to the class data, for the type of the object, in the method area. (Note: this is how getClass() is able to obtain the class for any instance whose type was loaded) But in the constant pool there is not such pointer, because such entries are not objects.
In page 290 and 291 of the book Inside the Java 2 Virtual Machine by Bill Venners says that "the resolution of such entries creates the String objects and they are interned" (not literally). The list of interned String objects is the pool we are talking about, but this list is not a part of the constant pool. This list must be an object (Collection?) to which the JVM holds a reference for the whole duration of the JVM.
Why it should be more dangerous for the JVM a program with many big String literals than a program with many big objects that are not made g.c. eligable?
 
Cindy Glass
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But I basically agree with everything that you just said, except that I should have said String literal table instead of String literal "pool" in the classfile (sorry about that - it confused the issue). Also the location of the String Pool is not dictated by the JVM Specifications.
After the JVM has resolved a class:
The runtime constant pool contains a list of references to Strings that were created by the class type.
The runtime constant pool lives in the method area.
The String objects that are being referenced live in the String Pool.
The String pool may or may not exist on the heap - depending on the implementation of the JVM.
The runtime constant pool never releases the references that it holds to string literals.
Therefore the string literals are never gc'd.
 
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just my 2 cents,
The JVM does not require String literals to be garbage collected.
There are some JVM's, for VM systems, that are optimized to gc String literals but the current and past versions of the standard Sun JVM's are not optimized to gc String literals.
Got that info straight from Peter van der Linden (a Sun employee and author of Just Java 2) back in January, 2001.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic