gc and the string pool

Consider the code snippet:String s1 = "The Tick!" ; String s2 = new String("Arthur"); s1 = null ; s2 = null ; How many objects are ready for gc? I'm thinking that there are two string constants from the string pool and they don't get garbage collected. Just the one string object that was created using "Arthur" - THAT gets collected. So what really happens? Is one or three object ready for gc?

Somewhere in your bytecode there will be an instance of a string object that says "goat" - otherwise, how would you specify what to make a new string out of? In this case, "goat" is a string literal. It is stored in the string pool. I'm guessing that anything that is in the string pool is not gc'd. Look at this code sample:

Since "goat" already exists in the string pool, s just points to it. When s is set to null, "goat" is not gc'd because it is part of the string pool. On the third line, s is assigned to the same instance of "goat". Suppose that we treated "goat" like any other string and it was gc'd after the second line? How would the third line work? I'm certain that string literals are not gc'd - but I do have some question about stuff in the string pool. Because you can make up a new string dynamically and move it into the string pool if you wanted to. Does that get gc'd? I dunno.

Well, I am just starting (exam in 10 days), so this question may sound stupid: Does printing to standard output create a string that's added to the String pool? If yes, and if gc doesn't care about String pool, shouldn't we run out of memory if we never unload VM?

Nope. The only stuff in the string pool is stuff that is a string literal (or stuff you specify is to be put in the string pool, but lets not go there now). So with

You have one string object in the string pool. It will not be gc'd. With

You have two string objects. One in the string pool and one in the regular heap. Both string objects contain the same thing. One will be gc'd and one won't. Suppose you call a program passing the argument SPARKY and your progrm has one line:

There are four string objects. One string object contains "arg is " and is in the string pool. The second string object contains "." and is also in the string pool. A third string object contains SPARKY". It is not in the string pool. A fourth string object contains "arg is SPARKY." and is printed to STDOUT. After being printed, it is ready for gc. I hope this helps.

<snip>You have two string objects. One in the string pool and one in the regular heap. Both string objects contain the same thing. One will be gc'd and one won't. What do you mean by this? That every String object will have a copy in the String pool? If that is the case, maybe the size of the pool is limited? I mean, when it reaches certain size, it starts writing on itself? Is that platform dependent? I tried to find something (not for very long) in documentation, no luck. Constant pool, heap, stack, my brain hurts! Nurse!

Tim Uckun

Ranch Hand

Posts: 88

posted 17 years ago

Given all of the above it would seem that if you plan on setting a variable repeatedly to different strings it's better to use the construct. s="This" ... some code .. s="That" Especially if keep setting the string over and over again. Is this right? Can you force gc on teh constant strings?

(for the stuff I'm about to say, I'll assume that the intern() stuff doesn't exist) The only stuff in the string pool are the string literals. That is anything appearing within quotes in your source code. Any strings that you create, or is created by something else, goes on the regular object heap and could be candidates for gc. The moral of this story is that there are only a few strings in the string pool and they are determined at compile time. All other strings are treated like regular objects.