2

As far as I know all the static variables and static methods will go on Static and all the methods, local variables and reference variable that declare in the method will go on Stack, but what about local variables and reference variables in a static method ? I guess they will be allocated on the Stack, but I am not sure how does it work.

For example:

 public static void A(){
      int x = 3;
      Point p = new Point();
 } 

Also I guess all the threads share Static as well as they share Heap, correct ?

peter
  • 8,333
  • 17
  • 71
  • 94
  • What is "go on Static" -- the heap? something else? – Sean Owen May 21 '12 at 19:21
  • 4
    I believe local variables go on the stack regardless of whether or not they are in a static method. – Hunter McMillen May 21 '12 at 19:21
  • I think he means the heap. In your example, x would be on the stack and p would be allocated in the heap. – Nick May 21 '12 at 19:24
  • @SeanOwen doesn't JVM have 3 sections of memory (stack, static, and heap) ? – peter May 21 '12 at 19:25
  • @Nick Is it always the case that all the reference variable (obj) will go on the Heap ? – peter May 21 '12 at 19:29
  • @user1389813 There is no `obj` in your example – David Heffernan May 21 '12 at 19:34
  • @DavidHeffernan the object(obj shorthand) he is referring to is the `Point` object – Hunter McMillen May 21 '12 at 19:34
  • The Point object is on the heap unless you have a Java implementation that can place it on the stack. But the reference variable `p` lives on the stack. – David Heffernan May 21 '12 at 19:43
  • So basically all static variables will be placed on the Heap as well as all the reference variables, and local variables that are primitive types will always place on Stack....correct ? – peter May 21 '12 at 19:47
  • As David pointed out. The 'p' reference variable (ordinary object pointer) is on the stack. But the object 'p' is on the heap. – Nick May 21 '12 at 19:51
  • @user Essentially that's correct. Subject to implementation details that could mean an implementation chooses to use registers rather than stack or stack rather than heap. But if that ever happens, it doesn't change the meaning so in your mental model you can safely think of stack and heap in the way you are doing. – David Heffernan May 21 '12 at 19:53
  • @Nick ... I am confused....does that mean the 'p' reference variable is pointing to the object 'p' that is placed on the heap ? I am wondering if that's the case.. will the object 'p' on the Heap be GC'd as soon as method A() returns ? – peter May 21 '12 at 19:59
  • @user1389813 yes it will be GCed whenever GC happens. – Nick May 21 '12 at 20:02
  • Where *methods* are loaded doesn't belong in this question at all. They are all loaded into the containing class's method area, wherever that is. – user207421 May 22 '12 at 02:01

3 Answers3

2

You can think of local variables as always being allocated on the stack of the executing thread. I guess JIT compiler could optimise them into registers, but semantically they are indistinguishable from stack allocated variables. Their scope and lifetime is private to each invocation of a function.

You also ask about static variables (class variables) and the heap. Class variables are shared between threads in the sense that references to class variables all refer to the same variable no matter which thread is executing. And likewise for objects that reside on the heap.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Whether the variable is static or non-static has nothing to do with threads. You can create a class that implements Runnable, have some static and non-static variables in it and create hundreds of threads that run that class. Those threads have access to both types. – Nick May 21 '12 at 19:31
  • @Nick That's true, but it's not the subject of the question. – David Heffernan May 21 '12 at 19:33
  • From OP: 'Also I guess all the threads share Static as well as they share Heap, correct ?'. Your answer mentioned threads as well before edits. – Nick May 21 '12 at 19:50
  • The answer still mentions threads. What OP is trying to get a handle on is whether or not threads get thread local copies of class variables or heap allocated objects. They don't. – David Heffernan May 21 '12 at 19:52
1

I don't think there is something called Static memory area. If it's primitive type variable it will be allocated in Stack and if it's reference type then the object itself is allocated in Heap, but the variable referencing to the address where object has been placed will be allocated in Stack. But the only thing different for static variables is that they will be initialized first and it's done by JVM, so they will be allocated first in Stack, before any other variables.

You can find more information here: static allocation in java - heap, stack and permanent generation

Community
  • 1
  • 1
artois
  • 11
  • 1
0

Every definition is put on the stack in the current context. Essentially, a new context is pushed onto the stack every time you have { and it is popped out of the stack when you have }. Then all variables declared in a given context are added to the current context at the top of the stack. When the context is popped, all the definitions in contained are forgotten.

This is why this works:

public void method() {
    {
        int x = 0;
    }

    // x isn't defined here

    {
        int x = 0;  // This doesn't conflict with the previous declaration of x because we just created a new context and the other one was popped before.
    }
}
mprivat
  • 21,582
  • 4
  • 54
  • 64
  • This is not quite correct. You are conflating compile-time actions and run-time actions. The lexical context is popped at compile time for declaration purposes, but all the space required for a method to execute is allocated on entry to the method at runtime. There is no bytecode instruction corresponding to the first } or the following { in your example. – user207421 May 22 '12 at 02:04