This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
Got some basic questions here, all related to Stack and Heap.
1. Where is stack and Heap are located in the PC or in a server?
2. Is stack is common to all the program language? Say i have Java and C++ in my machine, so both share the same Stack?
3. I read, Heap is inside the JVM and it has three major parts or generations, so can i say each language or compiler will have different Heap altogether?
4. In java program, how can i say a particular code is going to stack and a particular code is going to Heap?
With your answers i may have more questions on this topic.
sriram sundararajan wrote:1. Where is stack and Heap are located in the PC or in a server?
Both. Pretty much any computer running a Java program has a stack and heap.
sriram sundararajan wrote:2. Is stack is common to all the program language? Say i have Java and C++ in my machine, so both share the same Stack?
Most programming languages use a stack and heap, but they don't share stack and heap. In fact, even two Java programs (two separate JVMs) running on the same machine don't share the same stack or heap. In fact, if you have a single Java program (one JVM) that using multiple threads, each thread has a separate stack - but they all share the same heap.
sriram sundararajan wrote:3. I read, Heap is inside the JVM and it has three major parts or generations, so can i say each language or compiler will have different Heap altogether?
Well, a compiler probably doesn't use a stack or heap at all. Each language may have a different way of organizing a stack or heap. And there can easily be more than one stack or heap per language, as I discussed above.
sriram sundararajan wrote:4. In java program, how can i say a particular code is going to stack and a particular code is going to Heap?
Generally, local variables and parameters are stored on the stack, and instance and class variables (fields) are stored on the heap. Sometimes the JVM may perform special tricks that violate this rule. But we as programmers really don't need to care, most of the time. We just know the data is stored somewhere. Where doesn't usually matter.
Joined: Apr 08, 2003
I have a stupid question here, just to clear my understanding.
If stack is storing local variables and parameters and Heap is storing instance and class variables, why can't i have everything in a stack or a heap or a common storage space.
In lay man's language why i need two briefcases namely heap and stack, why can't i carry that in a single brief case?
The information that is stored in a stack and the information that is stored in a heap is not the same. There are different characteristics and rules for processing these distinct information sets. Having them in different locations fosters computing efficiency and execution speed, besides other things.
Think of your wallet/purse and your bank account. Some of your money is in your wallet/purse and some of your money is in your bank account. Why wouldn't you carry "all" of your money in your wallet/purse?
let's back up for a second...'stack' and 'heap' are overloaded terms. There is a data structure called a stack, and a data structure called a heap.
Most operating systems will give memory to processes (such as java) - i.e. when the jvm starts, your OS will say "Ok, the java process can have 2 gig of memory" or whatever.
Java then uses this memory in two ways - a stack, and a heap. They are generally though of as coming from opposite ends of a large contiguous block. The stack is often used for function calls and storing local variables. Each time you call a new method, a new 'block' is pushed onto the stack, with the local variables. each time you return from a method, you 'pop' it off.
The heap is used from the other end. each time you need a chunk of memory (i.e. use the 'new' operator), you need memory that you can hang onto for a while. There are various algorithms for where exactly you pick it from, how you recover it, how you clean it up, etc.
The reason I wanted to back up is this...you can have a stack in your method. the reference will be in the program stack, but the object itself lives in the heap.
confusing? a little.
Most modern programming languages give you a data structure called a stack - or you could write one. many also use a stack/heap for their own internal memory management. A Java and C++ program might both have stack and a heap, but won't share one. The OS would give java the memory from addresses 1000000 to 2000000 (which the JVM then divides into it's own stack/heap space) and C++ memory from 4500000 to 5500000, for example. It all comes out of the system memory. In fact, it's possible that the OS manages all memory with a stack/heap method, so you can have stacks and heaps (for the JVM) inside of stacks and heaps (the OS).
I think each time you start a new JVM, it will get it's own memory (although I'm less sure of this). It's not a language that is assigned a stack/heap space, but a process.
Never ascribe to malice that which can be adequately explained by stupidity.
Joined: Apr 08, 2003
Thanks for the reply.
Can you explain me a bit in detail. Take for instance, JVM has a stack and a heap. How it makes use of both. If it requires too elaborate details of JVM, atleast share me some URL's where i can find all the details.
I understand now, why we need stack and heap, but i would like to know the technical details of it.
The stack stores only* local variables. This is just the way the stack is built, in just about any programming language. You call a method, its local variables are pushed on the stack, and once the finishes these methods get popped out of the stack again. The stack is a somewhat linear piece of memory, and since each local variable has a fixed size** it is easy to maintain this memory. The heap on the other hand is just a big collection of objects, each with a potentially different size.
Now, why these two are not merged into one. You don't want to put objects from the heap in the stack, because that means that they are lost whenever the method finishes. You also don't want to put objects from the stack on the heap because it's less efficient; if a method finishes all these local variables need to be found in this big collection. The stack implementation simply decreases its stack pointer - the place in the linear piece of memory to look at next. See http://en.wikipedia.org/wiki/Call_stack for a bit more information.
* Ignoring the little trick Mike mentioned.
** References require a fixed amount of memory. This amount is different from the objects on the heap they refer to, and is usually just a 32 or 64 bits (better known as 4 or 8 bytes).