String Deduplication – A new feature in Java 8 Update 20

Related: I'm still frustrated by Java randomly (in a minor release, none the less!) switching to copy-on-substring. If I, a random nobody, had something that had its running time increased by a factor of ~50 (simple recursive-descent-ish parser for coercing tabulated data from one format to another - just call substring to trim off the first token repeatedly), how many dev hours were required overall to fix the results of the change? And there's no simple alternative either or way to preserve the old behavior - the simplest one, rolling your own String class or wrapper, ends up being relatively slow and annoying.

And "all" of this would be solved by having a proper way of doing array slicing - for things like substring's previous worst case (something like a single character being referenced in a substring holding up a gigabyte+-sized string) Java's garbage collector could recognize that the array was only referenced through slices of part of the array, copy that section into another array (updating references to it), and free the large one.

Also, Java's lack of a way to specify that a class is immutable (and that all children classes thereof must also be) is frustrating. Because optimizations like this can and should apply to more than just strings!

Here's a counterargument for this, just to be a fuddy-duddy:

One of the key activities in programming is reasoning about time and space cost, and this is a space optimization that's nondeterministic. It kicks in sometimes, or sometimes not at all, and happens behind the scenes at garbage collection time when it's nearly invisible. If you're sloppy, your program may have a huge asymptotic space usage, and this may paper over it. But the impl has heuristics, it may not work all the time -- even their example program needed Thread.sleep() calls! Unpredictable semantics help nobody. So I always liked explicit string interning (whatup, Lisp!).

All the same, faster is better and I'm sure this makes things faster.

Oh and can we talk about how broken it was that Java 6 and under had a fixed size pool for .intern()'d strings?

This sounds extremely valuable, if just because it requires far less tuning than interning strings.

Not so long ago I had to do maintenance on a pretty large Swing application, still stuck on Java 6, that was built around displaying huge amounts of data, holding it all in memory, after retrieving it from some rather slow web services. The poor thing easily ended up using about a couple of gigs, mostly due to the many Strings it held, many of them pretty repetitive. While I tried to reduce the memory footprint, I couldn't just intern everything coming from the service: In Java 6, interned strings come from PermGen.

Using a hashmap to allocate everything would have been better than nothing, but the dataset had a whole lot of strings that didn't repeat themselves, so the hashmap would have been far bigger than we needed for the application.

What I ended up having to do what to figure out where the data was the most repetitive, and then intern only those strings.

I cut memory use by over 30%, but it took days of profiling, evaluating the data and making simple code changes to get there, as opposed to just a runtime flag. Now, I wonder how much better, or worse, it performs that the hashmap solution in cases like the one I faced: a few hundred strings repeated tens of thousands of times, and hundreds of thousands of strings with almost no repetition.

For those interested in the same feature in plain old C, have a look at the DSO Howto, section 2.4.2 "Forever const" and the LD flags SHF_MERGE and SHF_STRING.

With a little bit of magic, C compilers and linkers are even allowed to turn (simplified example)

    const char s1[] = "some string";
    const char s2[] = "string";

into

    const char s1[] = "some string";
    const char s2[] = s1+5;

and place these constants in a read-only section shared between multiple loaded instances of the same library or program.

From http://openjdk.java.net/jeps/192

> Taking the above into account, the actual expected benefit ends up at around 10% heap reduction. Note that this number is a calculated average based on a wide range of applications. The heap reduction for a specific application could vary significantly both up and down.

Boost flyweight is pretty useful for doing this in C++

http://www.boost.org/doc/libs/1_56_0/libs/flyweight/doc/inde...

We once maintained a hashmap with key and value as the instance of string to avoid duplication in a search application. Wouldn't that be more beneficial than keeping it in GC if the application uses more strings?

Edit: changed avoid deduplication to avoid duplication

As a curiosity, global string cache is an old feature of R -- however strings are matched upon creation rather than detected by the GC.

Does this mean "" == ""?

This is only specific to the Oracle JVM.