Wednesday, January 07, 2009

Domingos Neto just postedBusting java.lang.String.intern() Myths. In general I like the post,because I think this is an important topic, because in my experience Strings typically consume about 20% to 50% of the memory in Java applications. It's therefore important to avoid useless copies of the same String, to reduce memory usage. But first some comments to the post above:

Myth 1: Comparing strings with == is much faster than with equals()

busted! Yes, == is faster than String.equals(), but in general it isn't near a performance improvement as it is cracked up to be.

I agree, it doesn't make sense to intern Strings to be able to use == instead of equals. But the real reason is that String.equals already does == in the first place. If your Strings are identical you automatically get the speed advantage because usually equals will be inlined!

Myth 2: String.intern() saves a lot of memory

Here I disagree. String.intern() can help you to save a lot of memory because it can be used to avoid holding duplicates of Strings in memory. Imagine you read a lot of Strings from some File and some (or a lot) of these Strings might actually be identifiers such as the name of a City or type(class). If you don't use String.intern()(or a similiar mechanism using a Set), you will hold copies of those Strings in memory. The number of this unnecessary copies will often increase with the number of Strings you read, and therefore you will really save a significant amount of memory.

That those interned Strings end up in Perm space IMHO is not a big issue. You need to setup perm space these days to pretty high values anyway, check for example my blog post about the perm space requirements of Eclipse.Still in the SAP JVM we also introduced a new option to store those interned Strings in the old space. Maybe someone wants to implement this option for the OpenJDK as well ;)

Issues with String.intern()Now you might think that String.intern() is not problematic at all, but unfortunately there are a few issues.

Not all JVM's have fast implementations for String.intern(). For example HP's JVM used to have problems until recently.

Additional contention is introduced and you have no control over it because String.intern() is native

Unfortunately I'm not aware of a good pure Java replacement for String.intern(), because what really would be needed is a memory efficient ConcurrentWeakHashSet. Such a Collection would need to use WeakReferences which have a relatively high memory overhead. Therefore my advice is still to use String.intern() if you need to avoid duplicated Strings.