Popular posts

Aakash Mallik

S/W Engineer @ Samsung R&D Delhi

Mar 19, 2018

As far as I know, there details are part of computer system architecture and you will be able to deal with these stuff if you were using C++ ( there may be other ways of doing it that I might not be aware of ). I will draw it out for you if you want.

Now as you can see, the stack grows downwards while the heap grows towards the top. Heap is dynamic memory and access to the heap is done using pointers in C++, hence a bit slow, but as it is accessed using pointers hence it can be accessed globally. This is the reason, global variable are stored in heap.

While on the other hand, local variables are stored in stack. Stack size is pretty limited and is usually done for variables used within a function and pretty much anything related to function calls and the more trivial stuff make use of the stack. That is why if you do a never ending recursion you will get a stack overflow.

Using the analogy I guess JS would use something of this sort under the hood. But the raw stack and heap thing can be visualised either by C / C++ or by assembly code.

How do I know this? Well I did a course on OS, so we had to do some coding that dealt with stack and heap. Pretty boring stuff.

Edit: The source code sits in the stack as well. And the mid point of the two, ie: stack and heap, that does not change, that is a static index.

Mark

formerly known as M

Mar 19, 2018

The heap doesn't grow in a fixed direction, for example, there can be holes which can then be filled (there's not really a direction at all, it's just memory).

Memory access isn't inherently slower for the heap, it's the (de)allocation that's slower. (Cashing and locking could also play a role, but no hard rules).

And you can have pointers to local variables, it's just not as useful because they are local (and thus disappear after the function ends).

M I am not trying to retaliate here but let's see if that correction was really necessary .

You say heap doesn't grow in a fixed direction, well what the statement means is that heap usually increments in towards addresses having higher index values. Holes can be filled by reallocating memory, true, but that is the whole point of dynamic memory. So, I don't see the need for that correction there.

Then you say heap memory is not inherently slower. "Because of this overhead from the search time, the heap is usually much, much slower than the stack. ... One common allocation technique uses something called an "arena," where a single large chunk of memory is allocated from the heap that is then partitioned into smaller blocks, like in the stack" - stackoverflow.

Which is intuitive to be honest coz finding and reallocating memory when you run out out space in a single contiguous block shall take more time than a linearly indexed stack.

Then you said you can have pointers to local variables; well have I mentioned that you cannot? But can you access heap without pointers? I guess not, hence I mentioned it explicitly for heap.

Thank you for your time though.

Search Hashnode