CODEWITHSUNDEEP
javastringstring-constant
Thaneshwar Sahu
Thaneshwar Sahu

Reputation: 27

Why String doesn't use scp only

We know that String create object in heap and scp based on situation but what if String use only scp for every situation, so that we can save some memory space

Upvotes: -2

Views: 187

Answers (1)

Stephen C
Stephen C

Reputation: 718738

Firstly, despite what you have heard or read, the Oracle documentation does not mention a thing called the "string constant pool". (Or "scp".) In fact, there are two distinct things:

  • The Constant Pool which is part of the ".class" file format and represents many the kinds of constants emitted by the compiler.

  • The String Pool is a runtime data structure that is primarily used to implement certain properties about String objects that originated as the result of compile time constant expressions.

But while the latter holds "constants", it can also holds String objects that were placed there by calling String.intern. So from that respect it is not a string "constant" pool. Alternatively, all String objects are immutable (constant), so from that perspective the "constant" in string constant pool is redundant.

In addition you say:

We know that String create object in heap and scp based on situation.

  1. In a modern JVM (Java 7 or later), the strings in the string pool are actually in the regular heap.

  2. The only situations where the JVM puts a string into the string pool are:

    • when creating a String object corresponding to a String-valued constant-expression in a .class file, or
    • when application code calls the String.intern method.

    No other string constructors or methods do it, and (AFAIK) none of the standard Java SE librarys ever use intern().

So to answer your question:

Why String doesn't use scp only?

Because when the String is not a duplicate, putting it into the pool doesn't save memory. Rather it uses more memory.

Because a String in the string pool tends to live longer beyond the point where it becomes unreachable. (This is certainly true for Java versions where the string pool was in the PermGen heap.) So you may end up using the memory for a pooled String for longer than if it hadn't been pooled. That can also mean that more memory is used overall.

Because searching the string pool each time you created a new string would be (relatively) expensive.

Because the string pool creates more work for the garbage collector. The pool is a native hash table data structure that contains references that are akin to Reference types. Searching or scanning the table to remove strings that are no longer reachable costs extra GC time.

Because ... frankly ... the percentage of memory used by (aka "wasted" on) duplicate strings is not significant in most applications.

Java tends to be memory hungry by virtue of being a garbage collected language. But it is memory hungry irrespective of string pooling. So if your application requirements include running in a minimal memory footprint, Java string pooling is not the solution. You should probably be using a different programming language.

In fact, since Java 9 there is a better way to save memory used by duplicate strings. Enable the GC's string deduplication feature. It is more efficient than interning because the deduping is only done on strings that have survived a number of new-space garbage collections. This reduces the wasted effort on deduping strings that turn out to be short lived.

Upvotes: 2

Related Questions