How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[James Kanze]

On Aug 17, 6:21 pm, Standish P <stnd... at gmail.com> wrote:
> > Garbage collection doesn't use a stack. It uses a "heap",
> > which is in the abstract a collection of memory blocks of
> > different lengths, divided into two lists, generally
> > represented as linked lists:

> > 1.  A list of blocks that are free and may be used to store
> > new data

> > 2.  A list of blocks that are in use, or haven't been freed (yet)

> Is this all that a heap is or is there more to it ?

There are many different ways to implement a heap.  The above is
not a good one, and I doubt that it's really used anywhere.

> I have been looking for simple but complete explanation of
> heap for a while and not gotten to it.

Complete in what sense?  The basic principle of how to use it is
simple.  As for how to implement it, there are many different
algorithms that can be used.

> I think I am looking for a stack allocation on the same
> pattern.

Stack allocation is far, far simpler (usually).

> In a disk, a file is fragmented in many contiguous blocks and
> is accessed automatically.

At the system level, the same thing holds for memory, and the
actual physical memory is "fragmented" into contiguous blocks,
each the size of a page.  The MMU (hardware) makes this
transparent to user programs, however.

> > There is no way you could do memory management of all but the most
> > trivial and fixed-length data chunks using a stack.

The length isn't the issue.  The order of allocation and freeing
is.  (For many specific uses, stack based allocators can and
have been used, but they don't work for generally allocation.)

--
James Kanze