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

[spinoza1111]

On Aug 18, 1:44 am, James Kanze <james.ka... at gmail.com> wrote:
> 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.

Actually, that's the only way to implement a heap in the abstract.
Forest and trees, mate. Mathematically a heap is a block of storage, a
list of free blocks and a list of allocated blocks. All the rest is
detail for the little techies to normally, get wrong. The confusion
between scientific and technical progress is a mirror of the (far more
serious) confusion between scientific progress and ethical advance.

Sure, when you free a block it is a good idea to see if you can join
it with its neighbors to get the biggest "bang for the buck". This,
again, is a detail relative to the grand plan which gives only techies
a hard-on, because the way scientific is confused with technical
progress is, in Foucault's terms, capillary. Part of ethical
regression is the overemphasis on efficiency and metaphors taken from
America's genocidal first use of nuclear weapons.

>
> > 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.

Correct, for a change.

>
> > I think I am looking for a stack allocation on the same
> > pattern.
>
> Stack allocation is far, far simpler (usually).

And very different.

>
> > 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