Java: Why is constant pool maintained only for String values ?

Question

My question is about java interning and constant pools.

Java maintains a a constants pool for java.lang.String, to use JVM memory cleverly, and to do so java.lang.String is made immutable. So why doesn't java maintain constant pools of other immutable types, such as Long, Integer, Char, Short ? Wouldn't that save memory too ?

I am aware of the fact that Integers are pooled for value range [-127, 127], though I do not understand the reason for choosing this range.

Here's a test code I wrote to test pooling of other immutable data types.

public class PoolTest {

    public static void main(String... args) {

        // Pooling of Integer [-127, 127]
        Integer x = 127, y = 127;
        System.out.println("Integer:" + (x == y)); // prints true
        x = 129;
        y = 129;
        System.out.println("Integer:" + (x == y)); // prints false

        // Apparent pooling of short [-127, 127]
        Short i = 127, j = 127;
        System.out.println("Short: " + (i == j)); // prints true
        i = 128;
        j = 128;
        System.out.println("Short: " + (i == j)); // prints false

        // No pooling of long values
        Long k = 10L, l = 10L;
        System.out.println("Long: " + (i == j)); // prints false
        k = 128L;
        l = 128L;
        System.out.println("Long: " + (i == j)); // prints false

    }
}

Answer 1

The purpose of a constant pool is to reduce the memory overhead required by keeping multiple copies of constants. In the case of Strings, the JVM is inherently required to keep some object around for each individually distinguishable constant, and the Java spec basically says that the JVM should deduplicate String objects when class loading. The ability to manually place Strings in the pool via intern is inexpensive and allows programmers to identify particular values (such as properties) that are going to be around for the life of the program and tell the JVM to put them out of the way of normal garbage collection.

Pooling numeric constants, on the other hand, doesn't make a lot of sense, for a few reasons:

• Most particular numbers aren't ever used in a given program's code.
• When numbers are used in code, embedding them in the code as immediate opcode values is less expensive in terms of memory than trying to pool them. Note that even the empty String carries around a char[], an int for its length, and another for its hashCode. For a number, by contrast, a maximum of eight immediate bytes is required.
• As of recent Java versions, Byte, Short, and Integer objects from -128 to 127 (0 to 127 for Character) are precached for performance reasons, not to save memory. This range was presumably chosen because this is the ranged of a signed byte, and it will cover a large number of common uses, while it would be impractical to try to precache a very large number of values.

As a note, keep in mind that the rules about interning were made long before the introduction of autoboxing and generic types in Java 5, which significantly expanded how much the wrapper classes were casually used. This increase in use led Sun to add those common values to a constant pool.

Answer 2

Well, because String objects are immutable, it's safe for multiple references to "share" the same String object.

public class ImmutableStrings
{
public static void main(String[] args)
{
    String one = "str1";
    String two = "str1";

    System.out.println(one.equals(two));
    System.out.println(one == two);
}
}

// Output

true
true

In such a case, there is really no need to make two instances of an identical String object. If a String object could be changed, as a StringBuffer can be changed, we would be forced to create two separate objects. But, as we know that String objects cannot change, we can safely share a String object among the two String references, one and two. This is done through the String literal pool.

You can go through this link to know in details.