Is stack allocation in Java implementation dependent?

Question

I've looked through the different threads, and there are a lot of conflicting information out there. The most useful article I found was this: Java theory and practice: Urban performance legends, revisited but it's from 2005.

So I was wondering what is the state of the Java standard regarding heap allocation. In the release notes for Java 7 it says:

(The server compiler) does not replace a heap allocation with a stack allocation for non-globally escaping objects.

I got the impression from the other article that this is indeed possible to do in the compiler, but it seems to not be required by the standard.

A related question which doesn't seem to answer my question is Stack and Heap memory in Java The accepted answer for this question says that only primitives may be put on the stack. There does not seem to be any consensus on that. Secondly, I'm obviously asking a different question.

I understand that in Java everything is a reference. That said, would a compiler allocate everything on the heap even if it is only reachable from a stack reference?

Answer 1

I was wondering what is the state of the Java standard regarding heap allocation.

It only takes a couple of seconds to actually grep the text of the Java Language Specification for all occurrences of the words "stack" or "heap" and inspect those, so the answer is not really hard: it doesn't say anything about stack or heap allocation. And why would it? That's an implementation detail.

The vast majority of hits for "heap" are talking about "heap pollution", which is the name of a condition that can occur with Java Generics, where a reference of a certain generic type can point to an object of a different type. However, this is just a name the designers of Java came up with, it's not necessarily related to a heap.

The vast majority of hits for "stack" are talking about the StackOverflowException. One hit talks about the fact that asynchronous exceptions which are constructed at one point in time but only thrown much later may construct the stack trace lazily. On the rest of the hits are in "example" sections, where the spec talks about how something may be implemented.

So, in short: no, the spec doesn't say anything really about stack and heap. It's perfectly possible to implement Java with only a dynamically resizable stack, and it's perfectly possible to implement Java with only a heap. Of course, you need to keep some information about the call graph, which you may very well do for example in a "stack" implemented as a linked list of heap-allocated stack frames.