13

I have a question

What happend when I declare a variable inside a method, for example.

void myMethod() {
    Ship myShip = new Ship();
}

Where is allocated myShip reference, in stack or in the heap ?

I think in stack but I'm confused because I was reading in J2ME Game Programming book "Java classes are instantiated onto the Java heap"

All java clases ?

Thanks in advance

trincot
  • 317,000
  • 35
  • 244
  • 286
iberck
  • 2,372
  • 5
  • 31
  • 41
  • This question is a little unclear as is. It could either be "Where is the reference to myShip stored in memory?" or "Where is the object pointed to by myShip stored in memory?" The conceptual answer to the former is the stack, and the conceptual answer to the latter is the heap, barring optimizations and crazy implementations, and there are answers answering it both ways. – Casey Rodarmor Feb 16 '12 at 00:20

4 Answers4

25

myShip is a reference to a Ship object, myShip is on the method call stack, which is referred to as "the stack". When a method is called a block of memory is pushed onto the top the stack, that memory block has space for all primitives (int, float, boolean etc) and object references of the method, which includes the method parameters. The heap is where the memory for the actual objects is allocated.

So myShip is on the stack and the Ship object is on the heap.

Note each thread has its own stack but share the heap.

nash
  • 3,020
  • 6
  • 38
  • 53
13

Java really does things a bit differently. The reference is basically on the stack. The memory for the object is allocated in what passes for the heap. However, the implementation of allocable memory isn't quite like the way the heap is implemented in the C/C++ model.

When you create a new object like that, it effectively puts the name into the table of references for that scope. That's much like a pointer to an object in C++. When it goes out of scope, that reference is lost; the allocated memory is no longer referenced, and can be garbage-collected.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
  • What about if it was just `Ship ship;` This means that the ship reference is on the stack, but no object is created. But does this mean that the `Ship` class is loaded at this point? – Joeblackdev Aug 13 '11 at 21:47
  • Really? I thought that doing that creates a Ship reference initialised with null. Is there a difference? – Joeblackdev Aug 14 '11 at 11:45
  • 3
    @CharlieMartin: You are wrong, Ship ship; do not construct a Ship! The variable is just initialized to null. – tibo May 17 '12 at 04:12
  • 2
    If it’s a local variable (i.e. a variable in a method), it is _not_ initialized to `null` unless you explicitely set it to `null`! – Bombe Jul 12 '13 at 12:12
  • I did test the code: Ship ship; System.out.println(""+ship)" and it event does not compile using javac 1.8.0_31 it tells me "ship might not have been initialized" so I think @Bombe is right – Vit Bernatik Apr 29 '15 at 18:47
6

Currently, all Java objects are allocated on the heap. There is talk that Java 7 might do escape analysis and be able to allocate on the stack, but I don't know if the proposal is finalized yet. Here's the RFE.

Edit: Apparently, it's already in early builds of JDK 7. (The article says it will also be in JDK 6u14, but I can't find confirmation.)

Michael Myers
  • 188,989
  • 46
  • 291
  • 292
  • 2
    Escape analysis doesn't affect the semantics of the code, however, so one should never need to rely on or assume its existence. – bdonlan May 19 '09 at 00:00
  • 2
    @bdonlan: Correct, however escape analysis (implemented since Java SE 6u23, btw) does contribute to today's Java not being the lame duck it was 15 years ago. – Franz D. Mar 07 '15 at 00:47
3

Notionally, the object goes on "the heap". Then, because it's a method-local reference, the actual reference will be on the stack. By "the" stack, we mean the native thread stack (i.e. the same stack that a local variable in C would be allocated on) in the case of Sun's VM at least, but I don't think that's actually a requirement (the JVM just has to have some abstract notion of "stack frames" that it allocates on each method call, be it from the native stack or not).

But... on modern VMs (with admittedly the possible exception of simpler embedded/mpbile VMs), there's really no such thing as "the" heap. In practice, there are various heap areas. The simplest of these is typically almost like a "mini stack", designed to be quick to allocate for objects that won't hang around for long and can probably be de-allocated almost at once.

As mentioned by another poster, a highly optimised JVM could in principle allocate object data on the stack and there are definite proposals for this. Although, as also mentioned in one of the references, a criticism of this is that the fast "eden" heap is almost like a stack anyway (just not "the" stack).

Neil Coffey
  • 21,615
  • 7
  • 62
  • 83