Why are reference types stored in heap

Question

I do know that in Java, (perhaps in .net too) , primitives are stored on stacks , where as reference types are stored on heaps.

My question was that I do not understand the proc/cons for this behavior. Why can't we reference a memory location inside our stacks instead? . I couldn't find a proper explanation as I googled ( maybe I suck at it) , but if you people can provide some insights I would be grateful

Thanks.

Answer 1

I do know that in Java, (perhaps in .net too) , primitives are stored on stacks , where as reference types are stored on heaps.

No. It does not depend on whether its a primitive or a reference. It depends on the scope whether the stack or the heap is used. Local variables are allocated on the stack, member variables are allocated on the heap when the object is instantiated.

See also Do Java primitives go on the Stack or the Heap?

My question was that I do not understand the proc/cons for this behavior.

Data stored on the stack only lives as long as your method is executing. Once the method is done, all data allocated on the stack is removed. Data stored on the heap lives as long as it is not discarded (which, in case of Java, is done in the background by the garbage collector). In other languages as C/C++, you explicitly need to delete/free data which was allocated on the heap.

Consider the following code snippet:

String someMethod() {
  int i = 0;
  String result = "Hello";

  i = i + 5;
  return result;
}

Here, a primitive (int i) is created on the stack and some calculation is done on it. Once the method finishes, i cannot be accessed anymore, and its value is lost. The same is basically true for the result reference: the reference is allocated on the stack, but the Object (a String object in this case) is allocated on the Heap. By returning the reference as return value, the object it references can still be used outside the method.

Answer 2

You can't generally store reference types on stack because the stack frame is destroyed upon method return. If you saved a reference to an object so it can be dereferenced after the method completes, you'd be dereferencing a non-existent stack location.

The HotSpot JVM can perform escape analysis and, if it determines that an object cannot possibly escape the method scope, it will in fact allocate it on the stack.