Where Does Java's String Constant Pool Live, the Heap or the Stack

Where does Java's String constant pool live, the heap or the stack?

The answer is technically neither. According to the Java Virtual Machine Specification, the area for storing string literals is in the runtime constant pool. The runtime constant pool memory area is allocated on a per-class or per-interface basis, so it's not tied to any object instances at all. The runtime constant pool is a subset of the method area which "stores per-class structures such as the runtime constant pool, field and method data, and the code for methods and constructors, including the special methods used in class and instance initialization and interface type initialization". The VM spec says that although the method area is logically part of the heap, it doesn't dictate that memory allocated in the method area be subject to garbage collection or other behaviors that would be associated with normal data structures allocated to the heap.

Heap vs String Constant Pool memory representation for Object

----------------------------------------------
|        Heap         | String Constant Pool |
|---------------------|-----------------------                      
|                     |                      |
|    "abc"  "abc"     |       "abc"          |
|      ^      ^       |                      |
|      |      |       |                      |
|     s1     s2       |                      |

As Andy Turner said, the new operator always produces a new instance. It is guaranteed by the JLS.

The only small wrinkle is that under certain circumstances (e.g. if escape analysis is enabled in certain JVM versions) the new operator might allocate an object on the stack rather than the heap.

Where the Hello will store in String Constant Pool or Heap?

String literals in your code go directly to the Sring pool. Calling intern() on them will do nothing. intern() will only make sense in cases where you are dinamically constructing Strings (in runtime, not compile-time). In those cases calling intern() will instruct the JVM to move this variable into the String pool for future usage.

String pool is created in PermGen area or Object area of Heap

The move to Metaspace was necessary since the PermGen was really hard to tune.

Also, it was difficult to size the PermGen since the size depended on a lot of factors such as the total number of classes, the size of the constant pools, size of methods, etc.

Additionally, each garbage collector in HotSpot needed specialized code for dealing with metadata in the PermGen. Detaching metadata from PermGen not only allows the seamless management of Metaspace, but also allows for improvements such as simplification of full garbage collections and future concurrent de-allocation of class metadata.

Is Java String constant pool shared across different JVMs?

A string pool can not be shared between different JVMs. It is implemented as a hash table of references to the actual String objects which live in the particular heap of each JVM. Since references to different heaps are not compatible, as each JVM has its own logical address space, the hash table can’t be shared.

There is a mechanism to share common data between JVMs, Class Data Sharing, which uses a preprocessed form of common libraries, usually of the JRE. Besides the class and member definitions and the byte code, this naturally contains all string constants, but that’s only the data, using the data to create a Java String object with a distinct identity and adding a reference to the pool is still subject to each JVM.

---

Related Topics