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:
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!
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.
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
9 comments:
Excellent post! (I posted a tweet for it.) As you mentioned, performance can be very different amongst the various JVMs. To expand on that just a bit, not all JVMs even support the concept of permanent space. In other words, perm. gen. is a JVM-specific implementation detail. IIRC, older versions of JRockit did not even have perm. gen. (I think it put class metadata in the "regular" heap.)
Things get more complicated when you think about the JVM's garbage collector, which of course is also very implementation dependent. As the original post pointed out, Sun's JVM does garbage collect perm. gen., but keep in mind that the algorithm used to determine when to collect it, how much, etc. is *not* the same as the algorithm for the "regular" heap.
Hi Greg(?),
Thanks!
You are right, there are completely different JVM implementations, and I always tend to forget that :]
It's also true that storing the interned Strings in old space does not help much performance wise.
It's "only" less likely that you will run into OOM Errors because old space is usually larger than perm space. OK, maybe you would have less full GC's if old space is greater than perm space.
Yes,in most JVM's today you also have a new space, where short living objects get reclaimed more efficiently. But IMHO this is not an advantage here, because I would only intern Strings which are long lived.
I guess you are javaperformance on twitter?
Regards,
Markus
So, guess intern() would be a nono in a j2me environment...
Or if it is set to null, does it get removed from the perm space ?
If you set it to null it will get removed after a full GC (typically, depends on the VM).
hell yeah I knew it, I saw this modification in some site but I can't remember where, and finally I found it, now mt work is more and my sexual life too with Generic Viagra.
because what really would be needed is a memory efficient ConcurrentWeakHashSet.
You need map alike interface not just set since you can retrieve the interned version off the set, although technically you dont need the values.
That's relatively easily implementable by linear probe table (Object[]/String[]) and either Unsafe.cas or AtomicReferenceArray but the latter may have more memory fences than needed (and extra cast).
As for the Weak part, I think it's easier just to cap the maximum references (or total string length) in the table and be done with than using Weak Refs, LRU eviction policy would cost dearly, though (2xCAS + loops on get to keep the stamp)
Hi Stanimir,
Sure you need a slightly different interface than Set offers, but you won't need keys *and* values, e.g. a ConcurrentWeakHashMap implementation would waste memory. I think we agree on that. The issue with weak references is that they have a relatively high memory overhead (don't remember the number). My JVM guru's here told me that the table used for String.intern has a much lower overhead. I don't have number whether the WeakReference overhead would be signifcant in practice, but it could be because you only would want to "intern" rather small Strings.
Regards,
Markus
In a report dragonica gold obtained by the newspaper, Dr. Francisco Meza dfo gold says adult film companies refuse to ddo plat cooperate with the investigation eve isk, and stage names for everquest plat performers make it difficult eq2 plat to track down partners. The Los Angeles faxion gold Times reports that fiesta gold health officials are struggling to flyff penya make headway on a probe, a process that gaia online gold is usually much more efficient when grand fantasia gold there is a disease iris gold outbreak.
In an gamegoldbuy blog interview with The guild wars gold Associated Press on knight noah Friday, Obama predicted loco gold that Congress would raise last chaos gold the debt ceiling, but he acknowledged legend of edda gold that he would have to offer lineage 2 adena more spending cuts in the budget mabinogi gold to get a deal. Later, Obama's spokesman perfect world gold said a debt ceiling vote ro zeny could not be contingent rf online gold on upcoming negotiations rohan crone over the budget.
"I think that what rift platinum we have to runes of magic gold become aware of rift platinum is that if we allow taxes shaiya gold to fill in the holes silkroad gold here, we are going to find that we are swg credits getting ever closer to the type of vindictus gold economies that exist in warhammer gold Europe, which are very heavily wonderking zed laden and not rapidly growing the ways zentia gold ours can," Greenspan said on NBC.
That is so awesome! The information you wish to give through this article is very informative. I have been waiting to read such wonderful piece of articles but was never lucky, but today I finally did become lucky because your article is just fabulous. I certainly appreciate the effort! keep up the good work!
Post a Comment