11 Replies - 7189 Views - Last Post: 07 September 2013 - 08:44 PM

#1 Michael26  Icon User is offline

  • DIC-head, major DIC-head
  • member icon

Reputation: 362
  • View blog
  • Posts: 1,534
  • Joined: 08-April 09

Question about Stack and Heap

Posted 15 July 2013 - 05:42 AM

This might sound philosophical but here it goes :)
Why is memory divided into stack and heap, in other way, why are some types stored on heap any some on the stack?
Is This A Good Question/Topic? 0
  • +

Replies To: Question about Stack and Heap

#2 Witchking  Icon User is offline

  • D.I.C Head

Reputation: 68
  • Posts: 188
  • Joined: 17-February 13

Re: Question about Stack and Heap

Posted 15 July 2013 - 04:36 PM

As i understand it, the stack is faster and is used to store the integral types in a LIFO structure, with each function call pushing its variables onto the stack and popping them off once finished. The heap is used for heavier types like objects, and is slower and unmanaged.

The reason for the divide seems to be that on the stack only the memory on top can be freed, which would become problematic if you had a big chunk of data in the middle that you needed to free.

This post has been edited by Witchking: 15 July 2013 - 04:38 PM

Was This Post Helpful? 0
  • +
  • -

#3 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2268
  • View blog
  • Posts: 9,482
  • Joined: 29-May 08

Re: Question about Stack and Heap

Posted 15 July 2013 - 05:14 PM

The heap is managed. It is Garbage Collection.

It's cheaper (quicker) to move and copy a pointer to an object, then it is move and copy that object.
Was This Post Helpful? 0
  • +
  • -

#4 Witchking  Icon User is offline

  • D.I.C Head

Reputation: 68
  • Posts: 188
  • Joined: 17-February 13

Re: Question about Stack and Heap

Posted 15 July 2013 - 05:37 PM

View PostAdamSpeight2008, on 16 July 2013 - 02:14 AM, said:

The heap is managed. It is Garbage Collection.

Managed by .NET garbage collection in the case of C#, while generally being unmanaged in contrast to the stack, no?

This post has been edited by Witchking: 15 July 2013 - 05:37 PM

Was This Post Helpful? 0
  • +
  • -

#5 Michael26  Icon User is offline

  • DIC-head, major DIC-head
  • member icon

Reputation: 362
  • View blog
  • Posts: 1,534
  • Joined: 08-April 09

Re: Question about Stack and Heap

Posted 15 July 2013 - 11:39 PM

I have read that Stack is used to track running code and has a limit of 1MB, and Heap is used for dynamic memory.
Primitive data types are not complex, they hold single values like int i = 0. Object data types are complex, they reference other objects or other primitive data types. In other words, they hold reference to other multiple values and each one of them must be stored in memory. Object types need dynamic memory while primitive ones needs static type memory. If the requirement is of dynamic memory, its allocated on the heap or else it goes on a stack.
Was This Post Helpful? 0
  • +
  • -

#6 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 581
  • View blog
  • Posts: 1,292
  • Joined: 24-April 12

Re: Question about Stack and Heap

Posted 05 September 2013 - 02:26 PM

*
POPULAR

Well, this is a month and a half late, but the heap and the stack are really two completely different things.

This stuff gets down to the heart of the way the computer works. It's not a C# thing. It's an Intel/AMD sort of thing.

Basically, the heap is where your data is stored. It's a very large chunk of memory that can be used to allocate little chunks of memory out of it. Of course "little" is a relative term. Basically, global scope variables should probably be allocated out of it. Anything "large", and by "large" I mean more than 4 to 8 bytes is likely to be allocated out of the heap. Basically, it is your program's memory unless you do something way out of the norm (like start requesting actual pages of memory directly from Windows which is what you would do for very large memory like if you have a "variable" that holds 3GB of data - I'm not even sure if you can do that in C#, as I tend to think of that as a C++ thing, but you have access to Win32 I think, so probably).

The stack, on the other hand, is really another animal. The stack is there to support jumping all around your code. Without the stack functions or methods or objects would be a nightmare.

Basically, the computer uses the stack to keep track of what it was doing before it jumped into that method call. So, when it gets back from the method call, it will know where it was.

One of the primary things that the stack keeps is the instruction pointer. All of your code is in memory. It is instructions in memory. The instruction pointer points to the "current" machine language instruction. It is at the very core of what the computer is. When it jumps into a method, it jumps to a basically random place in memory where the code for that method begins. The instruction pointer only holds one memory address. So, it loses its place every time it changes. It only represents what the computer is carrying out at that nano-second. So, it's on one instruction, then needs to jump into a method, and then when it's finished with the method, it needs to jump back to the instruction immediately after the method call. Without the stack. It would not know where to come back to.

So, the stack is kind of like a box sitting on a desk. The stack frames are like pieces of paper that the computer uses to write down what it's currently doing. When the computer jumps to another method, it writes down what it was working on on the stack frame paper and grabs a fresh new sheet of stack frame paper. So, as it goes through a lot of nested method calls, it may be five or six levels deep. So let's say it's 6 method calls deep. So the stack has 5 stack frames in the box, plus the current stack frame.

It can only use the current stack frame. If the analogy were perfect it would actually have the current stack frame on top of the stack of frames in the box.

But as it comes out of each method, it pops the stack frame off the top of the stack and throws it away. In other words, as it finishes a method, it throws away the piece of paper (stack frame) on top of the stack of papers. Then it has all the information it needs to get back to work on what it was working on before it did the method call, including the instruction pointer that tells it exactly what machine language instruction it was on, by looking at the stack frame (paper) that is now exposed by the one on top it threw away.

You can kind of think of the instruction pointer as pointing to the exact line in your code that is currently being carried out, but your C# code may translate to 20 machine language instructions or more and it's actually pointing to the machine language instruction in your command.

So, when it calls a method, it pushes the current instruction pointer into the current stack frame, as if it were writing it down on the piece of paper on the top of the stack. Then it allocates a new stack frame for it's current work that goes on top. And when the method finishes, it pops that top stack frame off and throws it away, which reveals the stack frame that has the exact instruction pointer value to reset the instruction pointer to to tell it exactly which machine language instruction it was at before it made the method call.

There are several things that go on the stack, but its mostly all registers and pointers. The registers are the big reason you have a stack. The instruction pointer is a register. The memory location that the stack frame begins and ends are registers. Then you have your standard registers.

Basically, computer memory is just way too slow to get anything done. Granted, processor and memory speeds improve every year. But nothing is as electronically fast as a register. Registers are super fast pieces of memory. It's been awhile since I've really worked with this stuff, but I think currently registers are 64 bits in size each. That's not a lot. But it turns out it's often too much because of the way they get used. I think 32 bit registers are much more practicle. I think you can access a 64 bit register as 8, 16, 32, or 64 bits. Anyway, everything the computer does in the CPU is done on the registers. Basically, nothing is actually done in memory. The way it works is you pull it into a register and you process it, and then you push it back out to memory and start working on something else.

So, the reason I go into registers here, is your registers are the primary reason the stack exists. The stack is there to store your registers between method calls. When you jump into a method, you push all your registers onto the stack (in the stack frame). Then you can use the registers in your method without worry what values they contained or storing them. When you finish the method, you can pop the top stack frame off and you have all your register values right as you left them to reload into the registers.

If you were writing the machine code yourself, you could tell it exactly which registers to store in the stack frame before jumping to a method. You can also store other values, such as a pointer to a variable or object in memory.

At one point, I think I knew what C++ put into a stack frame when it called a function or method. It's the C++ compiler that makes this decision and the rules have changed with different versions of Visual C++.

As for C#, I'm not sure I ever really knew what it puts in it's stack frames. Registers such as the instruction pointer. I can tell you that for certain. You can actually pull up the stack frame in Visual Studio. I did it in VS 2010 in C# the other day when I was trying to figure out what was going on during recursion. I'm suprised, but you can partially disassemble C# and look at the Assembler/Machine instructions your C# is being turned into. You can also peek into memory and watch memory locations. You can peek into the memory that the stack pointers point to and actuall watch the stack frame. I'm a bit in awe that you can do that in C#, since it's .Net and managed and all. I mean this is absolutely par for the course in C++; I was just surprised that you can do it in C#, although there are certain places where it goes into the .Net framework where it won't show you what its doing. But still, I was impressed with how much it does show you.

But you can actually watch the stack for yourself, if you know how to do it. It's really easy to bring up, but it helps tremendously if you know what you're looking at.

I was kind of amazed at some of the stuff that C# was putting in the stack frame during a method call. Basically, everything that was in scope at that point, although my method was fairly simple. I think there's kind of limited space on the stack, although I can't remember why at the moment other than registers are really small and it's mainly there to store the values of the registers between method calls.

Oh. I think a lot of it too is the fact that your local scope variables probably are already sitting in the registers before the method call since it was processing them. And they have their current values in the register. So, when you push the registers onto the stack, you're pushing your local variables onto the stack. Then you come back from the method call and destroy the top stack frame to reveal the stack frame that has exactly how your registers were before the jump to the method. Obviously, this is passing values by value because any changes you made inside the method are lost when you come back and reset the register to their previous value before the method call.

Anyway, the Kip Irvine book is one of the best modern books to learn Assembly Language, which is basically what we're talking about here.

This post has been edited by BBeck: 05 September 2013 - 02:48 PM

Was This Post Helpful? 6
  • +
  • -

#7 Michael26  Icon User is offline

  • DIC-head, major DIC-head
  • member icon

Reputation: 362
  • View blog
  • Posts: 1,534
  • Joined: 08-April 09

Re: Question about Stack and Heap

Posted 05 September 2013 - 03:14 PM

You sure did earn your pragmatic badge :)
Was This Post Helpful? 0
  • +
  • -

#8 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 581
  • View blog
  • Posts: 1,292
  • Joined: 24-April 12

Re: Question about Stack and Heap

Posted 06 September 2013 - 10:19 AM

Thank you. :-) I'm suprised they haven't given me the "long winded" badge yet. :-) ... or maybe that's what pragmatic means. ;-)

This post has been edited by BBeck: 06 September 2013 - 10:20 AM

Was This Post Helpful? 0
  • +
  • -

#9 Ryano121  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1362
  • Posts: 3,002
  • Joined: 30-January 11

Re: Question about Stack and Heap

Posted 06 September 2013 - 10:55 AM

I think by the time I got to the end of that post I'd almost forgotten what I'd read at the top :P
Was This Post Helpful? 0
  • +
  • -

#10 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 581
  • View blog
  • Posts: 1,292
  • Joined: 24-April 12

Re: Question about Stack and Heap

Posted 06 September 2013 - 11:05 AM

LOL
Was This Post Helpful? 0
  • +
  • -

#11 Michael26  Icon User is offline

  • DIC-head, major DIC-head
  • member icon

Reputation: 362
  • View blog
  • Posts: 1,534
  • Joined: 08-April 09

Re: Question about Stack and Heap

Posted 06 September 2013 - 11:25 AM

The team should make a badge for members who make posts over 200 characters long, call it "TL:DR" :)
FYI i did read it :)
Was This Post Helpful? 0
  • +
  • -

#12 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3623
  • View blog
  • Posts: 11,290
  • Joined: 05-May 12

Re: Question about Stack and Heap

Posted 07 September 2013 - 08:44 PM

LOL! I remember somebody in the game forum describing BBeck's posts as "A Walls of Text". Perhaps a "bricklayer" badge?

Despite the teasing, I hope that BBeck realizes that we do value the effort that he puts into the well though out posts. The times I don't always agree with him, he makes it very easy for me to understand why I don't agree with him, and also understand where he is coming from. The times I agree with him, I feel smarter because somebody much smarter than me articulated clearly what I could only hope to try to state.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1