1
  1. If there is only stack memory, no heap memory , what are the problems will be created? i think it will make programs very fast.
  2. i know objects are created in heap memory. but if objects are created in stack memory, what will be the problems? Why we created heap memory?

i read.

Stack

very fast access
don't have to explicitly de-allocate variables
space is managed efficiently by CPU, memory will not become fragmented
limit on stack size (OS-dependent)

Heap

variables can be accessed globally
no limit on memory size
(relatively) slower access
no guaranteed efficient use of space, memory may become fragmented over time as blocks of memory are allocated, then freed
you must manage memory (you're in charge of allocating and freeing variables)
variables can be resized using realloc()
Md. Nahidul Alam Chowdhury
  • 135
  • 2
  • 13
  • The idea that stack is faster to access than heap is, at best, partially true. It's true that *allocating* space on the stack is faster than allocating heap memory, but after that memory access is memory access. It's true that things close to the current top of the stack are more likely to be in cache, but if you start allocating lots of things on the stack, that benefit goes away, too. – Jim Mischel Aug 02 '16 at 22:16

1 Answers1

3

I would start with the advantages of heaps / disadvantages of stacks :

1. Allocation-order independent freeing : This is the most important answer to your question. If there was only stack based memory, you could not immediately free e memory area unless it is immediately on top of the stack. However, with a heap , you can free memory regardless the order of allocation requests. As in a dynamic software, you can not expect to know the order of free requests throughout the life cycle of your software, this is why you do not always want to use stack memory.

2. Determining the system-wide stack size : Another related point is that if there was only stack memory used , that means all threads in the system will have fixed memory. In that case, it would not be easy to determine the ideal default thread stack size. That would cause over-consumption of memory. Therefore this might lead us to out of memory issues even though there is actually unused enough memory. Regarding this one I suggest to look at this one: http://linuxtips.manki.in/2011/11/tweaking-stack-size-of-linux-processes.html

Areas where stack-like heap allocators can be useful : Game engines employ this technique. A good example is loading and unloading assets ( textures, shaders , 3d meshes etc ) during loading a level and unloading it. A stack like allocator is a natural solution as order of unloading assets will be the reverse of loading them. Here you can see an implementation : https://github.com/davidaug/stackallocator

Other issues with heaps : You can also consider these as more pros for stack as an addition to pros you mentioned in the question :

a) Multicore systems : Regarding stack-allocators another advantage is that there would be much less lock contention as allocation requests from different CPU cores is an important problem to solve for heap allocator design. As an addition to lock contention, you also have to deal with problems like false sharing. Regarding this one, you could look at http://www.drdobbs.com/parallel/understanding-and-avoiding-memory-issues/212400410

b) Fragmentation : The very first item I mentioned ( allocation order independent freeing ) is a must requirement. However, this also brings the problem of fragmentation : What is memory fragmentation?

Community
  • 1
  • 1
Akin Ocal
  • 431
  • 4
  • 8