7

This question is a follow up of my previous question

stack growth direction

I would like to know whether stack is created by a compiler or OS/architecture ? Also how does OS knows about these compiler specific things ? For ex: C++ allows variables to create data on stack and heap while java allows only heap.

Also if stack is created on heap as mentioned in the post how can system know about it because the system knows only about stack pointer and base pointer.

Community
  • 1
  • 1
brett
  • 5,379
  • 12
  • 43
  • 48
  • 2
    possible duplicate of [What and where are the stack and heap](http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap) – Byron Whitlock Aug 31 '10 at 05:16
  • 2
    I can't see how the two questions are connected from the point of view of Java. You do realize that the JVM effectively acts the platform/architecture in the Java world, do you? – Vineet Reynolds Aug 31 '10 at 05:18
  • @Byron This is just a follow up of my previous question. Also the question is not about knowing about the stack. From my previous post I was said that stack can be created on heap to prevent things like buffer overflows. So if created on a heap how can system know about this ? – brett Aug 31 '10 at 05:18
  • @brett, Yes and it is obvious you need to *get a basic understanding of what the stack and heap is*. Read the dupe answers carefully.You can create A particular stack data structure in the heap, but that isn't the fundamental stack structure we are talking about. – Byron Whitlock Aug 31 '10 at 05:23
  • @brett, I just read the comments on your last accepted answer. Memory is all the same but conceptually, stack = memory allocated at compile time, and heap = dynamically allocated memory. I hope that is clear. – Byron Whitlock Aug 31 '10 at 05:30
  • @byron we are talking about logical addresses right.For ex: 2 frames for stack are created on a heap. they both have different logical addresses and are not contiguous as created on a stack right ? – brett Aug 31 '10 at 05:31
  • @brett, 2 frames for a stack are created in **memory**. It is an implementation detail where the are actually located. Remember the Heap isn't a location, it is a data structure, just like a stack. And you will never have your stack frames being allocated in the heap datastructure. This doesn't mean they cant exist next to each other in **memory**. Where they are actually stored is up to the compiler , OS and architecture. – Byron Whitlock Aug 31 '10 at 05:34
  • @Byron: I believe that some virtual machines may actually create stack-frame type structures via heap allocation, but in the C world the compiler just does math on the stack pointer. – nategoose Aug 31 '10 at 18:56
  • @ByronWhitlock: "never have stack frames allocated in the heap". Wrong. There's 3 concepts here: "stack", "activation record", and "heap". The heap is place where one can get storage at runtime. A called function needs storage ("activation record") to manage its computation; it may be allocated from stack, or allocated from the heap. A stack is data structure that makes evaluating computations easy, by enabling LIFO access to values. A function may use a stack *within* its activation record; or it may use a globally available stack. See http://stackoverflow.com/a/1053159/120163 – Ira Baxter Nov 17 '14 at 02:19

4 Answers4

7

The stack is a memory location allocated for your program by the OS. Once it's allocated, the OS sets a register (on x86, it's esp) to where the stack is and then it starts your program. Compilers know that if they use the value in this register as the stack pointer, they'll be okay. Then they do whatever they want to do with it. The OS just allocates a zone. It doesn't care about how it's used after.

The OS doesn't know if your program will use mostly the stack or the heap. However, since most programming languages use the stack in a way or another, it knows it should allocate one. For instance, Java stores its objects on the heap, but most implementations of the JVM will use the stack to maintain call frames (and primitive local variables), so it needs the stack too.

zneak
  • 134,922
  • 42
  • 253
  • 328
  • for Java, it should read **a stack**, as we have one jvm stack for each running thread. – Andreas Dolk Aug 31 '10 at 06:02
  • In the executables header there is often a field for the mainthreads stacksize (field is set by the compiler and can normally be set with a linker option). Also, when creating stacks, one can often set the threads stacksize. – Markus Kull Aug 31 '10 at 06:34
  • JVM thread stacks may or may not be the same memory as the actual java program. This is complicated to talk about, but the JVM could keep up with a separate stack for each java thread from the its system stacks that it is using for it's native code. – nategoose Aug 31 '10 at 19:02
3

The stack is most definitely defined by the compiler, the OS allocates the space for it but that is relatively trivial. The stack is a dedicated place in memory that is used by the compiler (in so much as the compiler defines the instructions that use it) to control program execution flow and store local variables etc.

So the OS doesn't know about the compiler specific stuff. The stack is still stored in main memory it is just not part of memory that you (the programmer) can directly control.

radman
  • 17,675
  • 11
  • 42
  • 58
1

One Java virtual machine stack is created for each thread in the virtual machine. The stack stores frames and the content can not be manipulated directly except for push and pop operations of frames.

Frames are created each time a message is invoked and is used to store data and partial results, as well as to perform dynamic linking , return values for methods, and dispatch exceptions.

The language spec details, that a Java virtual machine stack is analogous to the stack of a conventional language such as C. So to me, it is obvious that the jvm stack model is coded and used in the jvm implementation and not provided by the host OS.

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
0

Traditionally the stack is the location where the return address for machine code calls were placed (so it can return when done). Hence there were instructions to easily access this location in memory.

It was quickly found that putting arguments to the call along with the return address was a very simple and efficient way of doing it. This has then grown to deal with local addresses etc.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347