Hi Jorge, Rowan,
On Tue, May 13, 2014 at 10:57:45PM +0300, Rowan Thorpe wrote:
> On 13 May 2014 21:46, Jorge Acereda Maciá <jacer...@gmail.com> wrote:
> > ..[snip]..
> > Am I missing something? alloca() just adds an offset to the stack pointer:
Yes, it was mentioned occasionally in this thread.
> This whole thread is fascinating :-) and while following up some of
> Q&A which has great answers and comments, many defending alloca(),
> most however explaining why it (and VLAs) are apparently a bad idea
> for anything other than guaranteed *small* chunks:
> One comment caused me to eventually stumble on Memory Pools:
> which seems like it might be one of the best compromises for what you
For the purpose of our discussion, dynamically sized arrays and alloca()
are equivalent. They both have the disadvantage that the stack may grow
But for an inherently recursive language like Lisp this is always a
problem; you may end up using rather large amounts of stack space.
Therefore, PicoLisp postulates "unlimitedness", by relying on the fact
that modern operating systems maintain the stack in hardware (MMU),
increasing its size up to the total available memory just as needed. It
is recommended to set "ulimit -s unlimited".
Still, PicoLisp tries to be economical with stack usage. At each
recursion or function call, as little memory as possible should be
consumed. For this reason, constant array sizes are not optimal, they
will increase stack usage _really_ fast.
So the argument against dynamically sized arrays and alloca() should not
be that they may use too much stack space. They _must_ allocate so much
stack space as is needed anyway.
A memory pool is not giving anything new. The PicoLisp heap is a memory
pool, but it is asynchronous to the stack. In princple, malloc() is also
using a memory pool, and uses the brk() system call to increase it. A
self-made memory pool might be more efficient than malloc(), because it
can be less general and thus simpler (as the PicoLisp 'gc'), but it
won't decrease the total memory usage (heap + stack), and involves more
overhead than the hardware stack mechanisms.
PS. Having said all this about "unlimitedness", in PicoLisp it is broken
as soon as coroutines are used. A single coroutine is limited in stack
size (but in turn there may be an unlimited number of coroutines, again
needing an unlimited stack). 'emu' is even worse in this regard, it
doesn't use the hardware stack at all, and a fixed size pool instead :(