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

[spinoza1111]

On Aug 16, 7:20 pm, Malcolm McLean <malcolm.mcle... at btinternet.com>
wrote:
> On Aug 16, 10:20 am, Standish P <stnd... at gmail.com> wrote:> [Q] How far can stack [LIFO] solve do automatic garbage collection and
> > prevent memory leak ?
>
> Most programs can be written so that most of their memory allocations
> are matched by destructors at the same level.
>
> However the allocations that can't be written this way typically tend
> to be the small frequently-called ones used for nodes in dynamic graph
> objects, or small resizeable buffers to hold strings and the like.
> This is where you get the performance hit with repeated calls to
> malloc() and free().
>
> So generally it's not worthwhile writing a stack allocator for a
> normal program. That's not to say there aren't a few individual cases
> where it can help performance. (See the chapter "Memory games" in my
> book Basic Agorithms for details about memory allocation strategies).

Even if it's a troll, it was droll.

In a language that of necessity has a runtime stack or something that
works like a stack (eg., a stack) one finds that the need for explicit
stacks is lessened. For example, in my compiler for [start shameless
plug] "Build Your Own .Net Language and Compiler [end shameless plug]
I did not need to use an explicit stack to do recursive descent.

Instead, I simply called finer grained procedures, passing the
compiler state as a parameter, allowing the runtime stack to manage
the return.

To build an explicit stack in this program would have been folly, for
it would have been necessary to either preallocate the stack and thus
legislate the maximum complexity of source code, or use a lot of
memory management in the pre-existing runtime heap.

You didn't tell us you published a book. Can you identify the
publisher?