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

Elizabeth D Rather erather at
Wed Aug 18 21:30:40 CEST 2010

On 8/18/10 12:09 AM, spinoza1111 wrote:
> On Aug 18, 1:21 am, Standish P<stnd... at>  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 ? I have been
>> looking for simple but complete explanation of heap for a while and
>> not gotten to it. I think I am looking for a stack allocation on the
>> same pattern. In a disk, a file is fragmented in many contiguous
>> blocks and is accessed automatically.

Stacks (at least as far as Forth uses them) and heaps are fundamentally 
different things.

>>> However, data structures of variable size, or data structures that
>>> merely take up a lot of space, don't play nice with others on the
>>> stack, so, we place their address on the stack and store them in
>>> another place, which was named the heap, probably, as a sort of
>>> witticism.

In Forth, they go in "data space", which might or might not be in the 
dictionary, and is almost never in a dynamically managed heap; certainly 
not on a stack.

> No, they're not. Stack based languages have seen better days and Forth
> (and the SL/1 language I supported with compilers at Bell-Northern
> Research) were last in fashion in the 1970s. Processors seldom could
> multitask, so it wasn't recognized that the stack could be a
> performance bottleneck, where stack operations cannot be pipelined or
> executed in parallel.

Lol.  Forth supported multitasking on every processor it was implemented 
on in the 70's, with blazing speed compared to competitive techniques. 
I have never seen stack operations to be a bottleneck.

> Forth had a snowball's chance because it forces ordinary programmers
> to think in Reverse Polish notation and is for the above reasons hard
> to pipeline, although of course it can be pipelined.

Mostly it had a "snowball's chance" because it was never picked up by 
the CS gurus who, AFAIK, never really took a serious look at it.


Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045

"Forth-based products and Services for real-time
applications since 1973."

More information about the Python-list mailing list