1. Introduction
Whenever we declare a variable or create an object, it is stored in the memory. At a high level, Java divides the memory into two blocks: stack and heap. Both memories store specific types of data and have different patterns for their storage and access.
In this tutorial, we’ll look at different parameters and learn which is the most appropriate area to store the String constant pool.
2. String Constant Pool
The String constant pool is a special memory area. When we declare a String literal, the JVM creates the object in the pool and stores its reference on the stack. Before creating each String object in memory, the JVM performs some steps to decrease the memory overhead.
The String constant pool uses a Hashmap in its implementation. Each bucket of the Hashmap contains a list of Strings with the same hash code. In earlier versions of Java, the storage area for the pool was a fixed size and could often lead to the “Could not reserve enough space for object heap” error.
When the system loads the classes, String literals of all classes go to the application-level pool. It is because of the fact that equal String literals of different classes have to be the same Object. In these situations, data in the pool should be available to each class without any dependency.
Usually, the stack stores the data that is short-lived. It includes local primitive variables, references of heap objects, and methods in execution. Heap allows dynamic memory allocation, stores the Java objects and JRE classes at the runtime.
The heap allows global access and data stores in the heap are available to all threads during the lifetime of the application, whereas the data stores on the stack have the private scope and only the owner thread can access them.
The stack stores the data in contiguous memory blocks and permits random access. If a class needs a random String from the pool, it might not be available due to the LIFO (last-in-first-out) rule of the stack. In contrast, the heap allocates the memory dynamically and allows us to access the data in any way.
Let’s assume we have a code snippet consisting of different types of variables. The stack will store the value of the int literal and references of String and Demo objects*.* The value of any object will be stored in the heap, and all the String literals go in the pool inside the heap:
The variables created on the stack are deallocated as soon as the thread completes execution. In contrast, a garbage collector reclaims the resources in the heap. Similarly, the garbage collector collects the un-referenced items from the pool.
The default size of the pool may differ on the different platforms. In any case, it is still much bigger than the available stack size. Before JDK 7, the pool was part of permgen space, and from JDK 7 to now, it is part of the main heap memory.
3. Conclusion
In this short article, we learned about the storage area for String constant pool. Stack and heap have different characteristics to store and access data. From memory allocation to its access and availability, a heap is the most suitable area to store the String constant pool.
In fact, the pool has never been a part of stack memory.