Basic Programming Skills

From Wiki Notes @ WuJiewen.com, by Jiewen Wu
Revision as of 19:05, 19 January 2009 by Admin (talk | contribs)

Jump to: navigation, search

Heap, Stack and JVM This topic touches upon stack and heap, i.e., the memory allocation, for programs in a simple way. Such topic may be relevant to CS134, CS115 at University of Waterloo.


A program is run in the memory of computers. First, a compiler compiles a program into a machine representation, which is stored at some location in the memory called code segment. Other than the program itself, we need some memory allocation for methods, parameters of methods and all variables defined in a method. These objects have their memory allocated in the stack segment. A stack is a LIFO (last in first out) data structure, which always pop or push elements in it at only one open end. Additional storage of memory, the heap segment, is required for global variables and static variables (as in C), which may exist during the whole lifetime of the program.


We look further at stack and heap segment in the context of JVM (Java Virtual Machine) here.

The JVM is "virtual" in that it is an abstract computer defined by a specification. To run a Java program, you need a concrete implementation of the abstract specification. Specifically, concrete implementations of JVM exist on many platforms and come from many vendors, either software or a combination of hardware and software. On the other hand, a runtime instance of JVM hosts a single running Java application. So, the fact is a Java application runs inside a runtime instance of some concrete implementation of the abstract specification of the JVM.

Memory allocation is part of the architecture of the JVM, which might complicate things that are necessary for CS newbies. Hence, we only take a look at the basics of memory allocation in JVM.

We assume that one thread is executing a Java method (non-native method). The thread has program counter (PC) register showing the next instruction to execute and a Java stack stores the state of Java method invocations for the thread, which includes its local variables, the parameters with which it was invoked, its return value (if any), and intermediate calculations. So whenever you see above items in a Java method, just remember that they will be put in a Java stack (which comprises stack frames, but we will not detail that).

On the other hand, as the program runs, JVM places all objects the program instantiates onto the heap segment. So, when you see a new() operator in a method, this object is created in the heap. Further, I have to say that each thread has its own stack, but the heap is shared by all of them, i.e., there is only ONE heap in a JVM instance. Recall that a Java application runs inside its "own" exclusive JVM runtime instance, so there is a separate heap for every individual running application. Different Java applications won't trample on each other's heap data. However, two different threads of the same application could trample on each other's heap data. That's why we need synchronization of multi-threaded access to objects (heap data) in Java programs.


Arrays in Java programs----

Like objects, arrays are always stored on the heap.