The Artima Developer Community
Sponsored Link

Java Buzz Forum
Is java.lang.String.intern() really evil?

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Markus Kohler

Posts: 74
Nickname: kohlerm
Registered: Jun, 2008

Markus Kohler is an software architect at SAP
Is java.lang.String.intern() really evil? Posted: Jan 7, 2009 2:53 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Markus Kohler.
Original Post: Is java.lang.String.intern() really evil?
Feed Title: Java Performance blog
Feed URL: http://feeds.feedburner.com/JavaPerformanceBlog
Feed Description: My blogs about Java Performance related topics
Latest Java Buzz Posts
Latest Java Buzz Posts by Markus Kohler
Latest Posts From Java Performance blog

Advertisement
Domingos Neto just posted
Busting 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.


In my experience duplicated Strings are one of the most common memory usage problems in Java applications.
Check for example my blog post about the Memory usage of Netbeans versus Eclipse.


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.

Read: Is java.lang.String.intern() really evil?

Topic: 2008 New Year's Resolution Previous Topic   Next Topic Topic: Links for 2008-12-31 [del.icio.us]

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use