{"id":28856,"date":"2018-06-28T14:51:20","date_gmt":"2018-06-28T14:51:20","guid":{"rendered":"http:\/\/www.sickgaming.net\/blog\/2018\/06\/28\/stack-vs-heap-whats-the-difference-and-why-should-i-care\/"},"modified":"2018-06-28T14:51:20","modified_gmt":"2018-06-28T14:51:20","slug":"stack-vs-heap-whats-the-difference-and-why-should-i-care","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2018\/06\/28\/stack-vs-heap-whats-the-difference-and-why-should-i-care\/","title":{"rendered":"Stack vs Heap. What\u2019s the Difference and Why Should I Care?"},"content":{"rendered":"
<\/div>\n

I\u2019m four months into the curriculum at\u00a0Holberton School<\/a>\u00a0and we\u2019ve solved multiple problems using the malloc, realloc, calloc and free functions in the C programming language. What better way to build a solid foundation of how memory gets allocated then to write a technical post on the stack versus the heap?<\/p>\n

This article explains in\u00a0depth:<\/h4>\n
\n

What are the five segments of memory?<\/p>\n<\/blockquote>\n

\n

What is the stack?<\/p>\n<\/blockquote>\n

\n

What is the heap?<\/p>\n<\/blockquote>\n

\n

How does understanding the two make you a better software engineer?<\/p>\n<\/blockquote>\n

What are the five segments of\u00a0memory?<\/h4>\n

When we write applications, files, or any logic that is typed in an editor and executed on the computer, the computer has to allocate memory for the program to run. The memory that is assigned to a program or application in a computer can be divided into five parts. The amount of memory that get\u2019s assigned to an application depends on the computer\u2019s architecture and will vary across most devices, but the variable that remains constant is the five parts of an application\u2019s memory which are the heap, stack, initialized data segment, uninitialized data segment, and the text segment.<\/p>\n

The\u00a0initialized data segment<\/em>consists of all the global and static variables that are initialized when a file gets compiled. The\u00a0uninitialized data segment<\/em>\u00a0consists of all global and static variables that are initialized to zero or do not have explicit initialization in source code.<\/p>\n

At Holberton, most of the time we are not concerned about the uninitialized data segment because when we compile our programs with\u00a0gcc<\/code>, we use the flags,\u00a0-Wall -Wextra -pedantic -Werror<\/code>\u00a0and we use an internal stylistic checker called\u00a0betty<\/code>\u00a0which treats warning as errors when uninitialized variables are present. Having unused variables in our programs gets flagged and is not a best practice. The\u00a0text segment<\/em>, also known as the code segment, contains the machine instructions which make up your program. The text segment is often read-only and prevents a program from accidentally modifying its instructions.<\/p>\n

What is the\u00a0stack?<\/h4>\n

The stack is a segment of memory where data like your local variables and function calls get added and\/or removed in a last-in-first-out (LIFO) manner. When you compile a program, the compiler enters through the main function and a stack frame is created on the stack. A\u00a0frame<\/a>, also known as an\u00a0activation record<\/em>\u00a0is the collection of all data on the stack associated with one subprogram call. The main function and all the local variables are stored in an initial frame.<\/p>\n

Program vs Stack\u00a0usage<\/p>\n

In the picture above, we have one stack frame on the stack that holds the main function, along with the local\u00a0a, b and sum<\/code>\u00a0variables. After using the\u00a0printf()<\/code>\u00a0function the frame we created along with the local variables are only accessible in memory for the duration of the frame are no longer accessible after returning the 0 value from the function.<\/p>\n

What happens with the stack when we call multiple functions? To illustrate the stack in it\u2019s\u00a0LIFO<\/a>\u00a0manner, let\u2019s solve a problem using recursion. When we call multiple functions in our application, we use multiple stack frames in a last-in-first-out approach meaning that the last stack frame we\u2019ve created on the stack is the first stack that will be released after the function is done executing its logic. Let\u2019s go over an example of printing out the name \u201cHolberton\u201d recursively and show how our code affects the stack memory segment.<\/p>\n

Yes, I have a whiteboard on the back of my door at my\u00a0house.<\/p>\n

When we compile our code using\u00a0gcc _putchar.c 0-puts_recursion.c 0-main.c<\/code>\u00a0, the compiler enters our program through\u00a0int main(void)<\/code>\u00a0and creates a frame with the function\u00a0int main(void)<\/code>\u00a0and\u00a0_puts_recursion(\"Holberton\")<\/code>\u00a0living on that frame as illustrated on the image above. When the compiler runs into the\u00a0_puts_recursion()<\/code>\u00a0function, it calls that function and creates another stack frame on top of the previous stack frame where\u00a0int main(void)<\/code>\u00a0lives. We are now in our second stack frame in our program and have entered in the\u00a0_puts_recursion(char *s)<\/code>function where\u00a0*s<\/code>\u00a0is equal to\u00a0'H'<\/code>\u00a0and is only accessible in that stack frame. Because\u00a0'H'<\/code>\u00a0does not equal\u00a0'\\0'<\/code>\u00a0, we will continue with our function calls and execute the\u00a0_putchar('H')<\/code>\u00a0function and enter into the same function\u00a0_puts_recursion(++s)<\/code>. The argument\u00a0++s<\/code>\u00a0moves the memory address of the\u00a0*s<\/code>\u00a0one byte because the size of a char is 1 byte on our machine, and now\u00a0_puts_recursion<\/code>\u00a0is calling the function as\u00a0_puts_recrusion('o')<\/code>\u00a0. Each time the\u00a0_puts_recursion<\/code>\u00a0function is called, a new stack frame is put on the stack until we hit the terminating condition which is\u00a0if (*s == '\\0')<\/code>.<\/p>\n

Every time a new stack frame is created, the stack pointer moves with it until it reaches the terminating condition. A stack pointer is a small register that stores the address of the last program request in a frame. When we hit the terminating condition, we execute our logic, then start to unwind the stack or pop off stack frames in the last-in-first-out manner until we reach out\u00a0return(0)<\/code>\u00a0logic in the\u00a0int main(void)<\/code>\u00a0function in our first stack frame.<\/p>\n

If you don\u2019t have a terminating case for the recursive example above, the stack will continue to grow in size adding additional stack frames on-top of each other, moving the stack pointer upward on each call, against the heap, which will be explained in the next section. In a recursive function\u00a0, if there is no valid terminating condition, the stack will grow until you\u2019ve completed consumed all the memory that\u2019s been allocated for your program by the operating system. When the stack pointer exceeds the stack bound, you have a condition called\u00a0stack overflow<\/em>. Bad things happen when you have a stack overflow.<\/p>\n

Let\u2019s first refer back to the other four segments of your application\u2019s memory which were the uninitialized and initialized data segments, text segment and stack segment. These four segments have a constant memory size during compilation. The memory size for these four segments is predetermined by your operating system before compiling your programs. When software engineers write programs that consume large amounts of memory from a machine, they have to consider where and how much memory is being consumed in their application.<\/p>\n

The max stack size is constant and predetermined before a program is compiled. At Holberton, we use a Linux Ubuntu\/Trusty64 distributions. To find information about the stack size and other neat limits, type the command below into your terminal.<\/p>\n

ulimit -a<\/code><\/p>\n

Where\u00a0ulimit<\/code>\u00a0is a function that gets and sets user limits and the\u00a0-a<\/code>\u00a0flag lists all the current limits.<\/p>\n

Stack size is 8.192MB of\u00a0memory.<\/p>\n

If the stack is limited in size and a program needs more memory for it to execute, where can a software engineer pull memory from for his\/her application? This is where the heap comes into play.<\/p>\n

What is the\u00a0heap?<\/h4>\n

The heap is the segment of memory that is not set to a constant size before compilation and can be controlled dynamically by the programmer. Think of the heap as a \u201cfree pool\u201d of memory you can use when running your application. The size of the heap for an application is determined by the physical constraints of your RAM (Random access memory) and is generally much larger in size than the stack.<\/p>\n

We use memory from the heap when we don\u2019t know how much space a data structure will take up in our program, when we need to allocate more memory than what\u2019s available on the stack, or when we need to create variables that last the duration of our application. We can do that in the C programming language by using\u00a0malloc<\/a>,\u00a0realloc<\/a>,\u00a0calloc<\/a>\u00a0and\/or\u00a0free<\/a>. Check out the example below.<\/p>\n

Allocating 4000 bytes of memory to our program, then releasing it.<\/p>\n

We allocate memory from the heap using the\u00a0malloc()<\/code>\u00a0function. The argument we want to include in malloc is the amount of memory we want to allocate to our application, in bytes.\u00a0Malloc<\/code>\u00a0returns a void pointer that is type casted into an integer pointer that now points to the first address in memory for our 4000 byte long memory. We can now store information in those memory addresses and do as we please to that information for the duration of our program or for the duration of our function because we have a pointer that references the first memory address from the newly allocated heap memory.<\/p>\n

If you aren\u2019t intentionally creating variables that last the duration of your application from the heap, you always want to release the memory back to the machine using the\u00a0free()<\/code>\u00a0function. If you don\u2019t release the memory using the free() function, you have memory that will persist throughout your program. If we do not release the memory from our program before terminating the application, our application has memory leaks. If your application has enough memory leaks, it can consume more memory than is physically available and can cause programs to crash. This is why we use a program called\u00a0valgrind<\/code>.\u00a0Valgrind<\/a>\u00a0is easy to use and checks for memory leaks.<\/p>\n

Valgrind being used. 4,000 bytes allocated. 0 bytes\u00a0leaks<\/p>\n

Another thing to consider while using the heap, the pointer variables created on the heap are accessible by any function, anywhere in your program, as long as the memory is still persistent and hasn\u2019t been free.<\/p>\n

How does understanding the stack and heap make you a better software engineer?<\/h4>\n

If you understand the advantages and disadvantages of using the stack vs the heap for your application, then it gives you a strategic advantage for creating scalable programs. You, the programmer, have to decide when to use memory from the stack vs heap based on each problem you are trying to solve.<\/p>\n

If you have a variable like an array or struct that needs to be stored in a large block memory, needs to persist throughout the lifetime of your application and could change in size throughout the duration of your program, then you should allocate it from the heap.<\/p>\n

If you need to create helper functions with variables that only persist within the lifetime of the function, then you should allocate memory from the stack. Memory from the stack is easier to keep track of because the memory is only locally available in the function call which does not persist after the function is completed and is managed by the CPU.<\/p>\n

Photo credit:\u00a0Gribble\u00a0Lab<\/a><\/p>\n

Questions, comments or concerns, feel free to comment below, follow me or find me on Twitter @ NTTL_LTTN.<\/p>\n

References:<\/h4>\n

My Code School. (February 23rd, 2013). Pointers and dynamic memory\u200a\u2014\u200astack vs heap. . Retrieved from\u00a0https:\/\/www.youtube.com\/watch?v=_8-ht2AKyH4<\/a><\/p>\n

Paul Gribble (2012). C Programming Boot Camp\u200a\u2014\u200a7. Memory: Stack vs Heap. [Blog post]. Retrieved from\u00a0https:\/\/www.gribblelab.org\/CBootCamp\/7_Memory_Stack_vs_Heap.html#orgheadline1<\/a><\/p>\n

GeeksforGeeks. Memory Layout of C Programs. [Blog post]. Retrieved from\u00a0https:\/\/www.geeksforgeeks.org\/memory-layout-of-c-program\/<\/a><\/p>\n

Sandra Henry-Stocker. (November 18th, 2012). NETWORK WORLD\u200a\u2014\u200aSetting limits with ulimit. [Blog post]. Retrieved from\u00a0https:\/\/www.networkworld.com\/article\/2693414\/operating-systems\/setting-limits-with-ulimit.html<\/a><\/p>\n

Valgrind Developers (2000\u20132017). Valgrind. Retrieved from\u00a0http:\/\/valgrind.org\/<\/a><\/p>\n

Die.net Linux Documentation. Retrieved from\u00a0https:\/\/linux.die.net\/<\/a><\/p>\n

\n
\n
\n
\n
\n
\n

This article was produced in partnership with Holberton School and originally appeared on\u00a0Medium<\/a>.<\/em><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

I\u2019m four months into the curriculum at\u00a0Holberton School\u00a0and we\u2019ve solved multiple problems using the malloc, realloc, calloc and free functions in the C programming language. What better way to build a solid foundation of how memory gets allocated then to write a technical post on the stack versus the heap? This article explains in\u00a0depth: What […]<\/p>\n","protected":false},"author":2,"featured_media":28857,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[],"class_list":["post-28856","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux-freebsd-unix"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/28856","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=28856"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/28856\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/28857"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=28856"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=28856"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=28856"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}