JVM Anatomy Quark #10: String.intern (2019)

the guava library has an interner that does exactly what you'd want for a cache of strings, without blowing up the jvm's internal code cache (which iirc is what String.intern() uses). https://guava.dev/releases/22.0/api/docs/com/google/common/c...

Isn’t this concept originally from C#? (Where interning is the default behavior)

Once upon a time I found string interning useful in conjunction with IdentityHashMap for quick lookup of lots of strings.

I don't think using String::intern makes sense, especially now that Java's garbage collector is capable of deduplicating strings (https://openjdk.org/jeps/192). In the past it could have been used to reduce memory usage when a given string was used a lot, but now there are better ways of dealing with that issue.

I never understood it, either. It would be useful (at least historically) in cases where you’re willing to give up performance in exchange for lower memory usage, and then, you’d still have to make good choices on what strings to intern and what strings not to intern (I think the standard example is a XML parser that may choose to intern all node and attribute names of a XML schema. If you’re parsing a large file using a DOM parser, that can significantly decrease memory usage)

Problem 1: it can easily depend on your input data whether interning is necessary to prevent out of memory exceptions.

Problem 2: there often are better solutions to memory usage than interning strings (for example, by replacing that DOM parser by a streaming one)

Problem 3: if you’re writing a library, you can’t know anything about the application that will use your code, so you have to guess whether interning some of the strings you create will help the user.

And of course, that’s historically. (Some) modern JVMs already deduplicate strings.

> Anything else other than the ability to reliably use == for String comparison instead of .equals()?

Sometimes that's key.

Why not use an int or some other token? Well then you have to garbage collect yourself. Maybe use your own class for the token though instead of a string? But then you still have to do half the garbage collection, as you need a weak map for lookup and possibly some cleaning infrastructure.

One common thing I've seen is an attempt to de-duplicate a poorly-crafted cache.

Let's say you have a cache with Map<Language, BusinessInfo>. After a while, the cache is quite large, and you want to reduce its memory usage. You realize within BusinessInfo, you have a MailingAddress, but it's not actually localized. You're duplicating millions of address lines for no reason.

You could split this out of your cache, but pulling that thread is a bit tricky. Instead, you decide to store addressLine.intern().

I've used String.intern() in genetic data analysis to reduce memory usage by a large factor. Lots of repeated Strings like "AA", "AB", "BB", etc.

I used it a long time ago in a program that read large structured text files. What was 100s of MB of text in memory became a fraction in size after interning the tokens.

You'll need to go back earlier than 15 years. ConcurrentHashMap and friends were added in 1.6, but String.intern has been in there since the beginning. Since Java shipped with Threads in the standard library, (but no memory model) that meant it would have been very difficult to do concurrent String deduplication yourself. If you agree string deduplication is needed, then String.intern() was a good implementation for a long while.

String.intern() also offers some other benefits for certain use cases. Earlier versions of java did not cache the String hashcode, which meant that to use Strings as hash table keys meant hashing a lot more. But, an interned string can be used in an IdentityHashMap, which was faster for a long portion of Java's early life.

(I worked on a moderately popular Java library that targeted Java 1.5 as the minimum version. It does occasionally come up useful, but only in specific, and increasingly rare circumstances)

The appropriate way to think of it is as an optimization that you will almost certainly never need. If you do, you'd typically confirm that by profiling your code. And it would merely be one of several other strategies that you could employ to save a bit of memory and cpu. I'm sure there are some niche domains where every ms of performance matters enough that you'd go through a lot of trouble for very marginal gains in performance. But otherwise, this should not be something you'd ever need.

I think using == for strings is a mistake even if they are interned, except of course in some very controlled circumstances internally in a library if it gives a performance benefit. I don't want to look at my code and need to know if I string is interned to know if it is correct.

It allows you to do this:

synchronised(bob.intern()) { //This block executes in parallel for requests with different values of bob, but sequentially for each request that has the same value of bob. }

If I didn't have to integrate with a weird 3rd party API where this was necessary, I wouldn't know about String.intern()...

I used it a few times for great effect, many years ago, when dealing with very data heavy Swing applications. We dealt with millions of rows of data, and some keys were strings with very low cardinality. Interning some of those columns lead to major reductions in memory usage: Tens of millions of copies of the same string aren't all that great for 2005 era laptop, as headroom between garbage collections, especially back in the day, could make a big difference. Now, the fact that the strings were comparable with == vs .equals? never bothered trying to play those games.

Now, could we have solved this with other ways other than interns? Absolutely: Just make deserialization code do mostly the very same thing, but done by hand and on the heap.

In today's JVM, if you are using the G1 garbage collector, you can get 99% of the memory savings almost completely for free with a VM parameter: You still pay for an extra object, just pointed to the same character array underneath. I'd argue it's one of the most underutilized flags out there: It's not uncommon to end up with half the memory footprint in many use cases, and memory savings are often runtime savings too. Now that we have this, maybe intern always loses, but it was definitely useful in the right circumstances.

I've seen it used in an old code base so that a specialized Map implementation could be used with String keys.

I'm not even sure of the name of the library it came from or what it was called - maybe "ObjectHashMap" or something like that - but its semantics were that it used reference equality instead of the structural equality used by a regular HashMap. As a result map operations depended on base Object.hashCode and reference equality which are constant and presumably very quick operations.

Using a regular HashMap, the map operations would depend on String.hashCode() and String.equals() which are O(n) in the length of the String - although the return value from hashCode is cached.

On reflection and this was an old code-base, I'm somewhat sceptical that this was a win given that String keyed-HashMaps are so common that I'd imagine a lot of JVM optimisation effort has gone into this area. I guess it would depend on the pattern of use. If the universe of String keys was known in advance, then I guess it operated like a poor mans perfect hash. On the other hand, this is the kind of optimization in Java which I've found to be unstable with performance varying significantly between JVM versions and platforms.

I share the feeling that I wish there were more resources out there. I've collected a motley set at https://justinblank.com/notebooks/jvmarchitecture.html, but I haven't found anything systematic.

Why is Java used in low latency systems? Isn't C++ a better choice there?

The "native HashTable" referred to here is the string hash table that's inside the JVM. The JVM has to intern strings from class files' string literals here, so it's all implemented in native code. The comment about performance probably refers to Java constantly improving in performance because of improvements to the JIT compiler, whereas that native HashTable in the JVM is pretty static in performance unless somebody rewrites it or if the C++ optimization gets significantly better. Essentially Shipilëv is saying that Java code gets faster more quickly than the C++ code in the JVM.