Does a garbage collector collect stack memory, heap memory, or both?

Question

I read lot of articles about garbage collection and almost all article tells about heap memory. so my question is "garbage collection collects stack memory or heap memory or both".

Tricrotic

Duplicate. https://mcmap.net/q/669199/-garbage-collection – Rumple

Answer 1

It collects heap memory. Usually, stack memory is collected automatically when the execution path reaches the end of the scope. e.g.:

void fun()
{
  int n; // reservation on the stack as part of the activation record
  ...
} // returning the stack pointer to where it was before entering the scope

In fact, in a language like C++, stack allocated variables are called auto variables.

Cupulate

Answer 2

Heap memory.

Garbage collection is a method of deallocating memory that isn't being used anymore. Sometimes the "isn't being used anymore" part is tricky. With the stack, as soon as a function returns, we can be confident (excepting programmer error) that the local variables aren't being used anymore, so they are deallocated automatically at that time in nearly every language/runtime.

Choplogic

Answer 3

The stack is called a "stack" precisely because it is a zone of memory which is managed with a "stack policy", aka LIFO (as Last In, First Out). If allocation on the stack was not done in "the stack way" it would not be called a stack but heap.

Garbage Collection was invented in order to cope with the problem of allocating things on a heap, i.e. such that you cannot predict which parts will be released first. GC is meant for memory allocation problems where stack management is not sufficient.

Weinert

Answer 4

Stack is last in first out so there is no need to garbage collect.

--corrected-- duh!

Faustena

Surely you mean last in, first out. – Document

Yes, but don't call me Shirley. – Samuele

Answer 5

the stack is where your method arguments and local variables lie. if you leave the method, the stack pointer is automatically decremented (or incremented depending on the specific implementation). This is true for most programming languages.

garbage collection in contrast only works on the heap.

Fernandofernas

Answer 6

At least in java, stack will be automatically de-allocated as you leave that stack frame, so there is no need to garbage collect.

I'm a java programmer so I don't have this problem, but in fact in C++, (I heard that) you will have to be careful with this because you can allocate objects on stack, and you can leave that stack frame, the object will be de-allocated and you can not use it anymore, etc.

Actinology

No. In C++, objects that are stored on the stack are automatically deallocated when the function returns. But you can allocate an object on the heap, and store the pointer to that object on the stack; then when the function returns and you leave that stack frame, you lose the only copy of the pointer, leaking the object. If C++ had garbage collection built in (it's optional) this wouldn't be an issue. – Vigen

@Dave Hinton: And You can pass a pointer to an object allocated on the current stack frame, to another stack frame, and be surprised, right? No? – Actinology

In Java, no objects are stored on the stack; it only holds references to objects there. All the actual objects are in the heap. After a Java method ends, the reference is lost, but the object in the heap remains. In C++, an object can be placed directly on the stack, and that memory area is invalid after the function ends. – Gawain

Answer 7

Unless you are using a profiler that none of us know about, heap is the major concern. This is because most people just react to whatever a highly acclaimed tool tells them. Please get to the end of this post to see that most profiling tools that point out statically allocated memory errors are usually correct. Profiling should go beyond simple leaks and garbage collection.

Let me give you an example in C:

#include <stdlib.h>
#include <string.h>

int main(void)
{
   char *am_i_leaking;

   am_i_leaking = strdup("Now, that's subjective!");

   return 0;
}

If the OS that runs this program does not automatically reclaim heap, I've caused a problem. I can't think of a modern OS that does not do that which is actually in use.

Now lets look at this:

char *foo(void)
{
    static char bar[1024];
    memset(bar, 0, sizeof(bar));
    snprintf(bar, sizeof(bar -1), "Do wa diddy diddy dum diddy do");

    return bar;
}

How your compiler allocates that is, well, up to your compiler. If you use it and can fiddle with the result, you probably have a broken compiler. Yet, if I have 100 threads entering that function at once, surely, the result is rubbish, unless my compiler magically figures out what I meant and introduces mutual exclusion or dynamic allocation without me having to worry about it, at which point we're back to profiling heap.

In short, in our lifetime, garbage collection pertains to heap. Count on some taking stabs at the stack in the future and trying to 'optimize' things, then count on that effort becoming an interpreted language that a bunch of CEO's will demand.

That doesn't mean ignoring memory errors is a good thing, no matter what the storage happens to be.

Bolection

Answer 8

Garbage Collector In Java works only on Heap memory and not on stack memory , because of the main principal that stack works on which is ( Last In First Out).That explains it all in itself.l i.e. when the end of scope of function is reached the stack is automatically empty.

Burkle

Answer 9

You don't cite any particular technologies, but the use is fairly typical across languages.

The garbage collector only works on the managed heap. There may be multiple heaps in a single process, some of which are not garbage collected.

Variables allocated on the stack are deallocated when a method returns. The garbage colletor will use those variables to find live references, but it will not collect the memory.

Chaeta