File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes String Literals and Garbage Collection. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "String Literals and Garbage Collection." Watch "String Literals and Garbage Collection." New topic

String Literals and Garbage Collection.

Rosie Nelson
Ranch Hand

Joined: Nov 06, 2001
Posts: 31
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.
Ragu Sivaraman
Ranch Hand

Joined: Jul 20, 2001
Posts: 464
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
Pervez Amin

Joined: Nov 04, 2001
Posts: 16
I heard it also that string literals not gc'd.
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
They are String objects actually. Just that they are created in the compile time...

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

[This message has been edited by Vikrama Sanjeeva (edited November 08, 2001).]

Count the flowers of your garden, NOT the leafs which falls away!
Prepare IBM Exam 340 by joining
Rosie Nelson
Ranch Hand

Joined: Nov 06, 2001
Posts: 31
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).]
Cristian Negresco
Ranch Hand

Joined: Sep 15, 2001
Posts: 182
In all the places it is written that String literals are not GC.
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" );

Phil Sharp
Ranch Hand

Joined: Nov 08, 2001
Posts: 40
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.
Cindy Glass
"The Hood"

Joined: Sep 29, 2000
Posts: 8521
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:
The tag item of the CONSTANT_String_info structure has the value CONSTANT_String (8).
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).]

"JavaRanch, where the deer and the Certified play" - David O'Meara
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Here there is program that shows how String literals are not g.c.ed
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?

SCJP2. Please Indent your code using UBB Code
Cindy Glass
"The Hood"

Joined: Sep 29, 2000
Posts: 8521
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.
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
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.

Jane Griscti
SCJP, Co-author Mike Meyers' Java 2 Certification Passport
I agree. Here's the link:
subject: String Literals and Garbage Collection.
It's not a secret anymore!