GC on Strings in Literal Pool

[Paul Salerno]

Hi guys, I wanted to further tighten up my notes on the subject of GC and strings in the literal pool. I know Val touched on this earlier, but I need to make sure I'm on the right track
Case 1:

String S = "kanga"
S = "Kanga" + "Roo" // S no longer references the
                    // orig string, however no GC
                    // since string in liter pool
int [] arr = {1,4,9,25}
arr [3] = 16        // reset 4th element
arr = new int[4]    // arr now references new obj
                    // where orig obj referenced 
                    // by arr is GC'd

Case 2:

  
public class NewGarb
{
   public static Object getInt()
   {
      Object rg = new Integer(3)
      Object dg [][] = new Object [1][2]
      dg[0][1] = rg  // reset element of matrix
      dg[0][0] = rg  // reset element of matrix
      rg = null      // I think GC should occur 
                     // here
      return rg      // book indicates rg object 
                     // is eligible for GC "after"
                     // call to getInt() returned

if one of my friends could show me where I'm wrong on this, I'd greatly appreciate it.

[Corey McGlone]

Originally posted by Paul Salerno:
Hi guys, I wanted to further tighten up my notes on the subject of GC and strings in the literal pool. I know Val touched on this earlier, but I need to make sure I'm on the right track
Case 1:

String S = "kanga"
S = "Kanga" + "Roo" // S no longer references the
                    // orig string, however no GC
                    // since string in liter pool
int [] arr = {1,4,9,25}
arr [3] = 16        // reset 4th element
arr = new int[4]    // arr now references new obj
                    // where orig obj referenced 
                    // by arr is GC'd

Case 2:

  
public class NewGarb
{
   public static Object getInt()
   {
      Object rg = new Integer(3)
      Object dg [][] = new Object [1][2]
      dg[0][1] = rg  // reset element of matrix
      dg[0][0] = rg  // reset element of matrix
      rg = null      // I think GC should occur 
                     // here
      return rg      // book indicates rg object 
                     // is eligible for GC "after"
                     // call to getInt() returned

if one of my friends could show me where I'm wrong on this, I'd greatly appreciate it.

In your second example, until the method ends, you still have two references to the object originally created and assigned to rg. The second and third lines assign the references inside the 2D array dg to reference that object. Therefore, that object can't be garbage collected until either the references inside dg are assigned something else or the reference dg is assigned something else or goes out of scope.
I hope that helps,
Corey

[Paul Salerno]

I can see how this dg matrix holds two rg objects. Nevertheless since rg is set to null, the return value would be null, no?
Could you tell me if Case 1 is correct?

[Duncan Allen]

Hey Paul,
I dont know if this helps... but
I find that the easy way to determine if an object is eligible for garbage collection is to write out the Objects created and their references.
In your second case posted here (correct me if i am wrong) but you have created three references to the Integer(3) object you created.
ie
rg---------pointsTo---Integer(3)
dg[0][1]---pointsTo---the same as above
dg[0][0]---pointsTo---the same as above
so... setting rg to null, the object (Integer(3))is still being used by your dg references (ie no GC).
Dont know if it helps, but i thought i might add my two cents.
Bonne Chance

[Paul Salerno]

Duncan and Corey, yes that does make sense.
Im still not 100% on case 1 yet, if anyone knows.

[Rob Ross]

S = "Kanga" + "Roo"
Both "Kanga" and "Roo" are String literals, ie, String object in the literal pool, and so will never be GC'd. However, the concatenation is NOT a literal. String concatenation is performed using a StringBuffer. After the StringBuffer does the concatenation, it's value is returned via a toString() call, which creates a new String and assings a reference to it in variable S. So now S holds a brand new String object, that is NOT in the string pool, so when S goes out of scope or gets set to null, this new String will be eligible for GC.

int [] arr = {1,4,9,25}
arr [3] = 16        // reset 4th element
arr = new int[4]    // arr now references new obj                    // where orig obj referenced             // by arr is GC'd

primative are NOT objects; they are NEVER GC'd.
However, you are correct that when you instantiate a new int[], the previous int[] is eligible for GC.

[Graeme Brown]

Originally posted by Rob Ross:
S = "Kanga" + "Roo"
Both "Kanga" and "Roo" are String literals, ie, String object in the literal pool, and so will never be GC'd. However, the concatenation is NOT a literal. String concatenation is performed using a StringBuffer.

No. Stringbuffer is only used if one of the Objects to be concatenated is on the heap. In the case of "Kanga" + "Roo" both of these are in the literal pool so the resulting concatenated String can be evaluated at compile time and also placed in the literal pool.

[Jose Botella]

Hello
Graeme is almost totally right.
The concatenation of literal strings is considered by the compiler as a constant expression with a value known at compile time. Thus the content of the concatenated string is placed in the constant pool.
To find out when this can be done read JLS 15.28
Be careful the constant pool is not the string pool. The constant pool holds the content of the String. There, the string is not an object, because objects only exist in the heap. The first time the virtual machine uses the entry in the constant pool it resolves it. In this process creates the string object, this time in the String pool in the heap.
To clear this kinds of doubts use javap -c MyClass

public class Test23
{    Test23()
     {System.out.println("hello" + "world");
     }
}
Method Test23()
   0 aload_0
   1 invokespecial #1 (Method java.lang.Object())
   4 getstatic #2 (Field java.io.PrintStream out)
   7 ldc #3 (String "helloworld")
   9 invokevirtual #4 (Method void println(java.lang.String))
  12 return

In line 7 there is "ldc #3". This bytecode pushes into the operand stack a reference to the String object that will be created when the virtual machine creates a string object that contains the same information that the entry number 3 in the constant pool holds.
The virtual machine resolves entry 3 in the constant pool, at least, before the first time it access the entry. In this program only line 7 uses the entry.
However

public class Test23
{    Test23()
      {    String notCompileConstant = "world";
   System.out.println("hello" + notCompileConstant);
      }
}
Method Test23()
   0 aload_0
   1 invokespecial #1 (Method java.lang.Object())
   4 ldc #2 <String "world">
   6 astore_1
   7 getstatic #3 (Field java.io.PrintStream out)
  10 new #4 (Class java.lang.StringBuffer)
  13 dup
  14 invokespecial #5 (Method java.lang.StringBuffer())
  17 ldc #6 (String "hello")
  19 invokevirtual #7 (Method java.lang.StringBuffer append(java.lang.String))
  22 aload_1
  23 invokevirtual #7 (Method java.lang.StringBuffer append(java.lang.String))
  26 invokevirtual #8 (Method java.lang.String toString())
  29 invokevirtual #9 (Method void println(java.lang.String))
  32 return

Because JLS 15.28 tell us that this concatenation is not a constant expression with a value known at compile time, the compiler can not create a cosntant pool entry for storing its content. Thus a StringBuffer is created.

[Jose Botella]

Paul, don't worry about string literals recollection because this is not a subject for the exam.
In case you are curious this post shows how string literals can be g.c.ed

[Rob Ross]

Originally posted by Graeme Brown:


No. Stringbuffer is only used if one of the Objects to be concatenated is on the heap. In the case of "Kanga" + "Roo" both of these are in the literal pool so the resulting concatenated String can be evaluated at compile time and also placed in the literal pool.

<rob slaps his forehead>
Yea, that's right. I knew that though. Honest. My brain just forgot to remind me that I knew it when I wrote that.

[ February 26, 2002: Message edited by: Rob Ross ]

[Paul Salerno]

you guys are awesome, thanks

[Paul Salerno]

Is this the same situation?
Here 4 string literal objects are created within a for loop and GC'd since temp is a local var.

public void process(int count) ---> pass 5
{
   for(int i = 1; i < count; i++)
   {
      Object temp = "Hello" + i;
   }
}

[Rajinder Yadav]

Rob, I beg to differ, a statement like
String S = "Good" + "bye";
will creates 3 string in the runtime constant pool, namely: Good, bye, Goodbye
only strings created using the new operator will be GCed
Compile and run the following code to see for yourself!

public class Test {
   public static void main(String[] args) {
      String s1 = "Good" + "bye";
      String s2 = "Good" + "bye";
      String s3 = "Goodbye";
      
      System.out.println("s1 == s2 : " + (s1 == s2));
      System.out.println("s1 == s3 : " + (s1 == s3));
    }
}

[ February 28, 2002: Message edited by: Rajinder Yadav ]

[Paul Salerno]

Does anyone have a clue about the last piece of code that I posted.
4 string objects are being created and I wanted to be sure that they WILL be GC'd.
TIA

[Rob Ross]

You are correct that 4 new objects are created, and they are all eligible for gc when the loop ends.
But they're not string literals.. only the string in quotes is a literal ("Hello"). If they were literals, they couldn't be garbage collected now could they!?
The new objects are String objects created via the String concatenation operator , "+".
But yes, they all are eligible for gc when the loop ends.

[Graeme Brown]

Originally posted by Rob Ross:

But yes, they all are eligible for gc when the loop ends.

True, but to be precise, each Object will be available for gc as soon as the assignment is made in the next iteration of the loop.

[Junilu Lacar]

Originally posted by Rajinder Yadav:
Rob, I beg to differ, a statement like
String S = "Good" + "bye";
will creates 3 string in the runtime constant pool, namely: Good, bye, Goodbye
[ February 28, 2002: Message edited by: Rajinder Yadav ]

Rajinder,
I think you have made the wrong conclusion there: only one String literal gets added to the string pool as a result of the code given:
String s1 = "Good" + "bye";
String s2 = "Good" + "bye";
String s3 = "Goodbye";
(s1 == s2) and (s1 == s3) are both true.
If you'd like further evidence, running this code through the javap utility will give:
0 ldc #3 <String "Goodbye">
2 astore_1
3 ldc #3 <String "Goodbye">
5 astore_2
6 ldc #3 <String "Goodbye">
8 astore_3
The compiler is smart enough to concatenate "Good" and "bye" at compile time since it can determine that the RHS is a constant string expression.
Junilu
[ March 01, 2002: Message edited by: Junilu Lacar ]