Programming: Computer Memory

    Programming: Computer Memory

      The computer memory buzzwords are heap and stack. Before programming, the only time Shmoop heard those words was when we tried to fold laundry.

      Key word: tried.

      But heaps and stacks have a completely different meaning from the pile of wet clothes still in our room. These words refer to types of computer memory and how we use them in programming.

      Heap memory and stack memory are allocated spaces in the computer. In terms of programming, the two types are ways of setting aside space to run a program in both the cache—the easiest to access and also the most volatile memory—and the RAM—the harder to access and slightly more stable memory. That isn't always the way programming languages handle cache and RAM, but…that's life.

      All data may be equal, but some data is more equal than other data. If your programming language distinguishes between primitives—the smallest pieces of data—and objects—collections of information—chances are the primitives sit in the stack/cache and objects sit in the heap/RAM.

      The stack is a space in the cache that acts like—you guessed it—a stack. As you add data in the stack, you "pile" one piece on top of another. If you want to access the data, you need to go through the last item first, working your way down the stack to find it.

      RAM, or Random Access Memory, stores data randomly, making finding it more complex. Even though it takes longer to find, it also has a lot more space than the cache. This is where the heap sits in your computer memory. Large chunks of information, like objects and classes, sit in the heap a.k.a. the RAM.

      That's all well and good, but what happens when you run out of space? Nuclear apocalypse, widespread famine, complete anarchy.

      Yeah, not so much. But it could kill your program or your computer if you aren't careful.

      When we start talking about running out of memory, we're talking about the objects. Primitive data types are neat and compact like Smart Cars. Objects, though, objects are real memory-guzzlers. Thank goodness they don't try to park curbside in the stack.

      When a variable has an object as its value, the variable sits in the stack but "points" at the object. The value of the variable, which sits in the stack, is actually the heap memory address of the object.

      We have to be careful though, because if we lose that pointer, we also lose the object. That's just wasteful. And the world doesn't need another gas-guzzler…erm, object.

      Suppose we have two variables that point at different objects. Then the second pointer somehow manages to point to the first pointer's object. Now nothing refers to that second object.

      Uh-oh.

      Okay, maybe the second object isn't important and we don't need to refer to it. But the memory's now both taken and inaccessible. If we keep assigning variables and losing objects, we'll have a memory leak.

      Some languages have garbage collection—a system of marking and removing inaccessible objects in RAM—or other forms of memory management to help this problem, but some don't and you just need to pay attention to all the memory you have used, are using, and will use in the future.

      You might need a spreadsheet.