In Java, is a global variable always put on the heap?

Question

Also, how does having a static variable affect things? (If at all) For example:

class MyClass{

     static int[][] data;

     static {
        data = new int[some number][some number]; /*read data into array*/
     }

     static void run() {
          /*now use data here*/
     }
}

Is this put on the heap? Comparing that example with

 class MyClass{

     static void run() {
          int[][] data = new int[some number][some number];
          /*now use data here*/
     }
}

How much difference is there between these two code examples? Please shed any insight.

Answer 1

Java has a concept of PermGen space - this is the space used to store all class definitions, static variables, interned strings, etc. here is link

This Java heap memory is structured again into regions, called generations. The longer an object lives, the higher the chance it will be promoted to an older generation. Young generations(such as Eden on Sun JVM) are more garbage collected than older generations(survivor and tenured on Sun JVM). However, there is also some separate heap space called permanent generation. Since it is a separate region, it is not considered part of the Java Heap space. Objects in this space are relatively permanent. Class definitions are stored here, as are static instances.

A full description of PermGen space can also be found here, although note that this is changing with Java 8: here is link

Static variables are stored there, dynamically allocated things are stored in the regular heap.

(Note that even for the static array the things placed within the array are dynamically generated).

Your second example is better for this case though unless you really need to remember the contents of that array between calls. You are using up memory all the time to store an array that you only need while you are inside the method. Additionally by having the static data like that your method is not re-entrant. That means that if two threads call the method at the same time then they will interfere with each other and give bad results.

Answer 2

Every object, that you create while your program is running, is created in the heap space. I think this is the most important thing to understand, when you are asking for antyhing "better".

A variable can be a local variable inside a method (method parameters are also local in this sense), or they belong to an instance or to a class. Here is the difference. The memory for local variables is allocated on the thread's stack, the memory for instance and class variables reside in the corresponding object's space, which is in the heap.

Keep in mind, that variables only store references to objects. They do not store the object! Therefore the memory consumption of variables is very low.

Answer 3

There are just two places where data can reside in JVM: the heap and the stack (well, JNI tricks inclusive it can reside anywhere, but this is an exception). All local variables in methods are located on the stack, everything else - on the heap. In both your examples array data is allocated on the heap, though in the second example the reference maze is a method local variable so is itself located on the stack.

Answer 4

One thing you must carefully distinguish is the following:

1. placement of the reference-typed variable;
2. placement of the referent (the array in your case).

If I follow your thoughts correctly, you are not really interested in 1., which is just four bytes, but in 2.

• If the variable which refers to the array is static, the array will be placed on the heap;
• if the variable is local, and if the JIT compiler can prove that your array will definitely not be reachable when your solve method completes, then there is a chance that the whole array will be stack-allocated.

For arrays, which are quite large, but efficiently allocated objects, it will make very little difference where they are allocated—as long as they don't get tenured into the Old Generation. If they do get tenured regularly, then you will probably experience significant slowdowns due to frequent Full GC cycles.