3

In Java, when we locally declare a variable, it goes in the Memory Stack, while locally defined objects goes to the Heap.

public class Clazz {
    private int x;

    // constructors omitted for brevity
}

public void method() {
    Clazz clazz = new Clazz(10); // defining an object - this goes to the heap space
    int y = 10; // declaring a varible - this goes to the memory stack
    clazz.doSomething();
}

Why do objects goes to the heap? Yes, I know that the Memory Stack has the reference to the objects in the heap, but why, unlike the primitives, the object values are stored in the heap?

In other words: why not put them all together, or in the memory stack or in the heap?

Edit:

Ok, got it. It's not a good idea to put the object in the memory stack, but why not put them all together in the heap, then?

This provides a good explanation on what the Heap is and what the Stack is, but unfortunately, doesn't answer my question.

Matheus
  • 3,058
  • 7
  • 16
  • 37
  • 2
    Because you want to use objects beyond the current stackframe? – akuzminykh Jul 07 '20 at 18:04
  • 4
    There's no reason to put primitives on the heap, and putting objects on the stack doesn't seem like a good idea. You want the object to persist for as long as there are references to it, and putting it on the stack would mean it wouldn't live past the method it's created in. Primitives, on the other hand, are copied each time they are passed somewhere. They don't have state and don't need to escape their stackframes – user Jul 07 '20 at 18:06
  • 1
    Primitives defined locally goes to `stack`. If a primitive were defined as part of an instance of an object, that `primitive` goes to heap. – Amit kumar Jul 07 '20 at 18:06
  • 1
    Putting primitives on the heap would be more work for the GC, because it'd need to trace references to it, and there's no real advantage to it, other than uniformity, perhaps, which isn't really worth it. – user Jul 07 '20 at 18:10
  • 2
    If there was no stack, you'd need a (very) clever and efficient way of deleting unused primitives. Why not using the simple and effective way of a stack? Where all you need for one stackframe just lives for one stackframe inherently. – akuzminykh Jul 07 '20 at 18:12
  • all good answers...but they are all comments, so I can't mark any of these as the solution ): – Matheus Jul 07 '20 at 18:26
  • 2
    @MatheusCirillo You can answer your own question, and add a summary of all these comments and other stuff you find online. I don't think anyone has asked the same question before, so you can turn this into a resource for future Stack Overflow users with the same query. – user Jul 07 '20 at 18:27
  • 2
    [What and where are the stack and heap?](https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap) - It's not focused on your question but it for sure answers it in many aspects if you see all answers as a whole. – akuzminykh Jul 07 '20 at 18:32
  • 1
    @akuzminykh I agree, there are some very insightful answers in that post. However, it's difficult to get a specific answer to this question from that post. If I search for 'why are Java primitives stored on the heap' I probably won't click on article explaining what stack/heap architecture is, ignoring language specific design decisions. – StuPointerException Jul 07 '20 at 18:57
  • 1
    @StuPointerException And that's why I haven't marked it as duplicate. ;) I agree. – akuzminykh Jul 07 '20 at 18:58
  • 1
    @akuzminykh Ha! I didn't mean to make it sound like I was 'accusing' you! :) – StuPointerException Jul 07 '20 at 19:03

1 Answers1

3

Primitives are a known size, up to 8 bytes. Storing a primitive on the heap would require up to 8 bytes of heap space and 4/8 bytes of stack space to store the reference (which is still required to see if the memory is still referenced - see the comment above by @akuzminykh). So it would potentially double the amount of memory required without giving any benefit. Stack space is also cleared up neatly, without having complex garbage collection, so as well as memory efficiency it also improves processing overhead.

A reference to an object is 4/8 bytes, while the object itself can (in theory) be any size, it would not be good to store this on the stack (as you pointed out).

StuPointerException
  • 7,117
  • 5
  • 29
  • 54