Stored area of immutable classes

Question

In recent interview, I was asked if string is stored in string-pool, as it supports immutability then where are our custom immutable classes are stored in java.

I have given below explanations - All the class variable primitive or object references (which is just a pointer to location where object is stored i.e. heap) are also stored in heap. Classes loaded by class-loader and static variables and static object references are stored in a special location in heap which permanent generation.

But the interviewer kept arguing that - If String has string-pool, can immutable classes also have some concept like that ?

Please can anyone explain regarding storage area of immutable classes as they are also immutable like string ?

Answer 1

In recent interview, I was asked if string is stored in string-pool, as it supports immutability then where are our custom immutable classes are stored in java.

This is a nonsensical question with a wrong premise. Strings are not “stored in string-pool”, they are stored in the heap, like any other object. That’s a kind of tautology, as the heap memory is precisely defined as “The heap is the run-time data area from which memory for all class instances and arrays is allocated.”

The string pool can be seen as containing strings, just like a Collection may contain objects, but in either case, it’s just holding references to objects. So a string contained in the pool still is stored in the heap memory, by definition, while the pool has a reference to it.

But the interviewer kept arguing that - If String has string-pool, can immutable classes also have some concept like that?

That’s an entirely different question. Of course, you can implement a pool of objects, as the Collection analogy above already indicated. Like strings contained in the pool are still stored in the heap memory, objects of your class are still stored in the heap memory when being referenced by whatever data structure used for the pool is referencing them. It’s not even necessary for the object to be immutable, to have such a pool, but the implied sharing of instances would cause semantic problems when mutations are possible. So creating a pool usually only makes sense for immutable objects.

For example, lots of the wrapper classes have such sharing, the valueOf methods for Short, Integer and Long will return shared instances for values in the -128 … +127 range and implementations are allowed to share even more, whereas Byte and Boolean return shared instances for all possible values.

However, there are reasons why not every immutable class implements a pool for all of its values:

• If there is a large value space, you have to consider supporting garbage collection of unused objects, even when referenced by the pool
• You have to consider the thread safety of your pool
• Both points above may lead to a complex solution with a performance penalty that you don’t want to pay when the object is only used for a short time, as sharing only reduces memory consumption for long living objects

This applies to the existing examples as well. The wrapper objects only provide shared objects for a limited value space. Which are preallocated and never GCed. The string pool on the other hand, is dynamic, thread safe and supports garbage collection of its elements, which is the reason why intern() is not a cheap operation and should not be applied on every string. Instead, the pool is primarily used for constants, which are indeed long-living.