16

Every time when I initiate a list in java, I will do 

List<Integer> list = new LinkedList<>();

I assume that this will allocate the list on heap. Wonder if there's anyway that I could allocate the list on stack?

trincot
  • 317,000
  • 35
  • 244
  • 286
user2640480
  • 1,899
  • 2
  • 13
  • 8
  • 1
    Why do you want it to allocate on the stack? – Puce Apr 24 '14 at 15:44
  • Is this purely academic? – wvdz Apr 24 '14 at 15:44
  • 2
    @LuiggiMendoza PermGen was not stack memory. It was where classes and other structures expected to exist for the remainder of the JVM process were allocated; moving these to a separate space made garbage collection in the regular heap more efficient. As class unloading became more routine, this efficiency gain became less clear. – erickson Apr 24 '14 at 15:49
  • 1
    `list` is on the stack, however this is a reference and the actual object(s) are on the heap. – Peter Lawrey Apr 24 '14 at 15:53
  • 2
    @PeterLawrey but only if it's a local variable. If it's a member variable it will be on the heap as well. – Puce Apr 24 '14 at 16:12
  • @Puce in theory, escape analysis can perform object elusion and the member fields will be on the stack as well. In practice, this almost never happens. – Peter Lawrey Apr 24 '14 at 16:14

2 Answers2

16

All objects, including their individual attributes, are stored on the heap.

All local variables, and their arguments, are stored on the stack because they contain primitive values or references.

However, in special cases, the java virtual machine may perform escape analysis and decide to allocate objects (including your LinkedList) on a stack, but this normally doesn't happen and isn't a major concern.

As a general rule, if you allocate an object on a stack you will get a copy of the object when you call a function that refers to it. In contrast, if you allocate an object on the heap, when you pass the pointer to the object you will get a copy of the pointer (which points to the very same object on the heap.)

manan
  • 1,385
  • 13
  • 23
  • Then how about C++? It seems C++ can allocate a list on stack by doing "list a;". And then it can perform any operation desired. – user2640480 Apr 24 '14 at 15:49
  • 1
    @user2640480 This only places the first/root object on the stack, the rest of the nodes will have to be on the heap. – Peter Lawrey Apr 24 '14 at 15:52
  • @user264080 as a general rule, if you allocate an object on a stack you will get a copy of the object when you call a function that refers to it, but if you allocate it on the heap, when you pass the pointer to the object you will get a copy of the pointer (which points to the very same object on the heap.) – manan Apr 24 '14 at 15:56
  • In this way, even in C++, I guess I cannot return the object (allocated on stack) as function returns because it will be popped up with the stack. Is that right? – user2640480 Apr 24 '14 at 15:57
  • When an allocation is done on the "stack", does this refer to the JVM stack, or to the C/C++ stack used for C/C++ locals? – nanofarad Aug 19 '16 at 11:55
13

It is theoretically possible for JVM implementations to allocate objects on the stack, using "escape analysis." If it can be determined that a reference to a created object never leaks off the stack, a JVM could allocate it on the stack instead of the heap. The benefit of this would be to reduce garbage collection overhead; when the stack frame is exited, that memory could be immediately reclaimed. It might also boost speed because of the locality of reference.

Starting in Java 7, escape analysis was introduced in the Oracle's HotSpot Java runtime. With this enhancement, HotSpot may choose not to allocate stack-local objects that aren't modified; rather than allocating them on the stack, it deletes the allocation altogether. While this stops short of stack allocation, it does demonstrate that such things are permissible runtime optimizations.

There is no way for the Java programmer to directly control this behavior, however. It's an optimization performed by the JIT compiler. I'm not sure if the language specification would permit this sort of optimization at compile-time. It might, but I haven't studied it.

erickson
  • 265,237
  • 58
  • 395
  • 493
  • As far as I know [EscapeAnalysis](https://wiki.openjdk.java.net/display/HotSpot/EscapeAnalysis) appear at Java 6 version 17. There is [detailed investigation of condition](https://stackoverflow.com/a/43002529/548473) – Grigory Kislin Dec 27 '18 at 16:27