Jump to content
 Share

_Rocket_

The Basics #3: The Stack and Heap

Recommended Posts

Posted  Edited by _Rocket_ - Edit Reason: Fixed a couple typos and improved readability

Introduction

Allocating memory in RAM for variables is something that on the surface sounds simple. But like most other things in both software and hardware, there are very small details that make huge differences.

If you have ever branched off from any high level languages like Java, Python, or Lua, you've likely ran into a single topic that might even confuse you to this day. Stacks and heaps. These two things are the names for procedures. Procedures used to allocate memory in RAM to store variables and instructions. But what is the stack? What's a heap? How do they work?

 

You have already learned about why things are stored in RAM, and what stores it there. But unless you have done research on this topic yourself, you may not know exactly how that memory is allocated. Some would think the CPU would start at memory address 0 and work its way up... but we all know how inefficient that is. If you are truly curious about how these processes work, then hopefully this will clear some of your questions.

 

What is the "Stack"?

The Stack is something that you surprisingly don't see in too many languages. This is because for many languages, the stack is overkill. The Stack is a fast way of allocating memory in RAM. The process that the stack follows goes like this:

 

The initialization:
When a program is launched, a very interesting thing takes place. In the stack, memory in RAM is pre-allocated before any instructions that you have written are ran. What this means is, the program finds a section in RAM large enough to allocate memory that the program will use later. To this day I have not gotten a consistent answer to how much memory is allocated for the stack, but the range is usually 1-8 Mb.

 

The Allocation of Variables:
To be able to visualize this properly, I should elaborate what "pre-allocated" meant. What the stack does is essentially "claim" a chunk of memory in your RAM. If you have a few GB of RAM, 8 mb is absolutely nothing. This means that as soon as you run your program, 1-8 mb of RAM is already "in-use". I like to visualize it as RAM that is inside RAM. The actual RAM stick pretty much shares a very small chunk of it's memory to the software, and now the stack can use that shared memory as its very own RAM stick.

 

When you declare a variable using the stack, an instruction called "push" is executed. This newly created variable will then be placed at the very top of the stack. This memory is now been claimed by a variable, so to the stack, this memory is no longer claimable by any new variables.

 

The Lifespan of Variables:
Lifespans of variables and how scopes work will be covered in the next tutorial. But for now, just know that stack variables only last as long as the scope lasts. If you do not know what a scope is, a tutorial will cover this topic very soon.

 

The Management of Variables:
The Stack has its name for a reason. Imagine the stack as being a stack of plates. Each plate has a different material and design to it, and they are all stacked on top of each other. When you want to add a new plate, you place it on top of that stack. If you want to grab a plate and use it, you take a plate from the top of the stack. This is known as a LIFO, or a "Last in-First out" operation. Whatever was last added to the stack, it will be the first object popped out when you go to grab that plate.

 

This is how memory is managed with the stack. The memory as stated before is already pre-allocated by the compiler upon launch. But this pre-allocated memory can be overwritten by data given to it, almost as if it's a micro-sized RAM stick.

 

The way the CPU accesses this memory is through an instruction named "pop". Pop is the only way to get data from the stacks memory. And this instruction tells RAM to pop out the object at the very top of its stack. Much like how you grab a plate from a plate stack. Once this is popped out from the stack, it gets stored in a high-speed pointer that the CPU can quickly use. This process is automated and handled by the stack itself. This is why creating pointers to stack variables can be dangerous if they aren't made globally.

 

What is the "Heap"?

The heap is the most common way of storing variables in RAM. A lot of languages use the heap for its storage, mainly because they aren't designed in a way that gives the stack any use.

The heap isn't unique like the stack. Your entire RAM stick is available to the Heap. This means that all allocation is done through the RAM stick itself, though the process of finding that memory is a little complicated and will be covered in a second.

 

The Allocation of Variables:
The allocation of variables is rather compiler-dependent. But the most common way (from what I know at least) of finding memory to allocate variables to goes something like this: Imagine a revolver. The revolver is named due to the thing that holds the ammo, which is also named the revolver. You could imagine the heap as a revolver with a bunch of different avaliable addresses in RAM. It has all of this in standby, and once the heap is called upon, it will give out the necessary storage needed... Please note that this is heavily boiled down. In all reality, the way the heap works is very complicated. I might cover it more in depth at a future time because the way the heap actually works would require an entire topic post to explain.

 

The Lifespan of Variables:
The lifespan of a variable stored in RAM through the Heap process is actually pretty dependent on what language you are using. For most languages, the language itself handles heap variables. Specifically mid to high level languages. In these languages, a Heap variable will act a lot like a stack variable in regards to its lifespan. So if you tried to use a pointer to point to a variable when the scope its located in was already removed, it will likely crash your program.

 

The Management of Variables:

The way Heap variables are managed are the main reason to why it's uncommon to see them used in low level languages. All the variables currently stored in the heap must be on a list for the program to access. Of course the way this "list" works is also pretty complicated, just know this information has to be stored. Unlike the stack, where all variables are in one place and accessed through a pointer, the variables stored through the heap are accessed dynamically. They are stored dynamically. That's really the main difference between the stack and heap process. The stack is more static. The heap is more dynamic.

 

Due to how the heap works, allocating and accessing these variables take longer. This difference in speed does not really matter for high level languages, but languages like C++ are impacted. Anyone who uses low level languages use them for efficiency and performance. Otherwise it's usually just overkill. So a low level language may use the stack by default, while high level languages use the heap by default.

 

High Level Languages

A high level language does not mean what some may think it means. It does not mean "level of difficulty". If anything, lower level languages are the more complicated languages to program with. What the phrase "high level" actually talks about is its level of optimization. High level languages are incredibly optimized. These optimizations range from how variables are handled, how objects are handled, how compilers compile code, etc. Typically, the higher the level, the more complex and advanced the compilers are. This is why Python can look so different from Java, for example. Python compilers are vastly different in how it reads your hand written code, and how it translates it into code that the computer can read. In fact, Python's compilers are so advanced they can handle datatypes for you.

 

The Stack and How its Used

For almost all high level languages, the programmer is not given the option to use the stack as a means to store variables in memory. Any use of the stack is done through the compiler or the language itself. Something that programmers have zero control over.

 

The Heap and How its Used

The heap tends to be the default method of storing variables into memory for mid to high level languages. Unlike low level languages, the compilers of high level languages are designed to handle heap variables for you. This is why some newer programmers who start with high level languages do not learn about the heap or the stack until later on. The reason why the heap is so automated is due to how advanced the compilers are. These compilers are very precise and well-crafted. And they are designed to handle a lot of things so you don't have to. This is what makes a high level language "high level". This is also why high level languages tend to be easier to write programs with.

 

Low Level Languages

A low level language is the polar opposite of high level languages, go figure. These languages tend to be older ones. Ones designed in an era where a lot of the work was done by the programmer. Due to this, compilers are usually "simple" (when compared to high level language compilers). Compiler designers tend to start with low level languages when they are beginning to learn about how designing a compiler works. This also means some of the work is reliant on the programmer.

 

The Stack and How its Used

The stack is very often the default method for storing things into memory. In fact, assembly code is so low level, you are the one responsible for managing the stack. Though, besides assembly, stack variables are usually completely automated. You can use pointers to point to stack variables. But it is very suggested you only do this to global variables/objects and not local ones.

 

The Heap and How its Used

The heap is... very different in low level languages. In high level languages, a lot of what happens with the heap is managed by the language and the compiler itself. You don't have to worry about a thing. Again, high level languages have high level compilers. But in low level compilers? Using the heap is pure hell and agony.

 

Even in C++, which is a borderline low-level language (imo), nearly everything that happens with a heap variable is in your hands. First of all, the only way to use the heap is usually done through the "new" keyword. The funny thing is, you actually have to have a pointer variable to use it.

 

The reason why using the heap is bad isn't just due to its slower performance. Constantly de-allocating and re-allocating a single heap variable can lead to inconsistent memory leaks and bugs. These have the potential of crashing your program. Just... don't use the heap in low level languages. Unless you want to go through the hell of managing these damn things, I suggest you stick with the stack.

 

If you need a little more on how these things work, here's a video I linked before you can use for review on stacks. The heap is very weird and I quite frankly am not for sure what I could link here. I personally need to do more research on how the heap works because there are a lot of areas I am unsure on or completely uneducated on. The heap is weird, man.

 

Edited by _Rocket_
Fixed a couple typos and improved readability

I write programs and stuff.

 

If you need to contact me, here is my discord tag: Dustin#6688

 

I am a busy person. So responses may be delayed.

1840045955_Thicco(1).thumb.png.87c04f05633286f3b45b381b4acc4602.png

 

Share this post


Link to post
Share on other sites


For those who are wondering, I will be publishing #4 of this series. I just plan on doing something a little special for it, but I'll need some time to get to it and get it done.


I write programs and stuff.

 

If you need to contact me, here is my discord tag: Dustin#6688

 

I am a busy person. So responses may be delayed.

1840045955_Thicco(1).thumb.png.87c04f05633286f3b45b381b4acc4602.png

 

Share this post


Link to post
Share on other sites


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...