How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
Elizabeth D Rather
erather at forth.com
Wed Aug 18 15:30:40 EDT 2010
On 8/18/10 12:09 AM, spinoza1111 wrote:
> On Aug 18, 1:21 am, 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 ? 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.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
More information about the Python-list
mailing list