The story with String literals?

[erikd]

Hi there,

This is a non-gameprogramming-and-although-java-still-off-topic-question (tm)  

I read that Strings literals are stored in an internal pool of unique String values.
This implies that every next String literal you have, takes longer to be created because it needs to check if there is another literal String instance in the pool with the same value.
Is this really true? Doesn't this also indirectly imply that the bigger your program gets, string literals get slower?

I found this somewhat disturbing, but I don't know how this impacts real-life programs: I could also imagine that it could in fact be faster in real-life programs than with String being a primitive like C (although I could also imagine that if this is in fact true, such optimizations can be done at compile time in C).

Has someone done tests/has experience with this? (if not, I'll might do it myself).

Greetings,
Erik

[princec]

You're half right I think; literals are stored in a pool, which might slow classloading a teeny weeny bit, but new instances of strings aren't. As they're not literals, of course.

Cas

[cfmdobbie]

Yeah, unless you intern() your created Strings, they won't appear in the internal pool.

Games published by our own members! Go get 'em!

[erikd]

... but I was talking about literals wasnt I (not explicitly created String objects)?  

But of course you're right that it will only affect class loading and not negatively affect runtime performance.
It will even speed up runtime performance when doing String literal comparing by using == instead of String.equals()  

Heh, I understand again  

[leknor]

I don't mean to hijack ericd's thread but since we have an answer to that I'd like to extend the thread by asking:

When is it desireable to use String.intern();?

[Ceranith]

I don't mean to hijack ericd's thread but since we have an answer to that I'd like to extend the thread by asking:

When is it desireable to use String.intern();?

I've never found it useful myself, but maybe if you want to speed up performance if you have a high number of String comparisons over creation of Strings. You'd gain efficiency checking if the references are equal rather than checking the contents of the String.

[Herkules]

If the pool is implemented as a HashSet e.g., checking for existance is O(1). So time can be constant no matter how much literals are there.

[Themroc]

I wouldn't use String.intern() unless there is a method to free the Strings again (I didn't found one when I looked some time ago at it).
String-pools can be very nice, I once built my own little log-file-scanner for my website and as many log-entries had same Strings (like requested path, address etc) I could save several MB of memory by using a pool for them.

[erikd]

You mean the pool is not subject for garbage collecting?  
I kind of assumed it would.

[Themroc]

You mean the pool is not subject for garbage collecting?  
I kind of assumed it would.

The API description does offer no hint that there might be some special treament of interned Strings, which would mean no GC.

But here is what I found in the net:

http://mindprod.com/jglossinterned.html

Intern and garbage Collection
In the early JDKs, any string you interned could never be garbage collected because the JVM had to keep a reference to in its Hashtable so it could check each incoming string to see if it already had it in the pool. With JDK 1.3 came weak references. Now unused intered strings will be garbage collected.