Re: Enlarge MAX_ALLOCA?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jun 2014 14:28:08 -0400
> 
> > Does anyone see problems with the change below, which raises the bar
> > for 'alloca' to 64KB?  Are there any systems out there that we care
> > about whose stack is so small as to make this dangerous?
> 
> It makes the potential max increment of stack space "per
> lisp-eval-depth" larger, and hence increases the risk that we'll eat up
> our stack before we bump into max-lisp-eval-depth.

Which functions relevant to max-lisp-eval-depth use SAFE_ALLOCA?

> The idea behind the 16KB limit is that the cost of malloc+free is likely
> to be negligible compared the filling and using 16KB of data.

I'm talking about the long-run costs, not the immediate ones.

> I think it makes a lot of sense to try and allocate this space on the
> stack when decoding file names, but why does it allocate such a huge
> buffer just to en/decode a puny file name?

That buffer is fixed in size, I don't know what.  Perhaps it's hard to
know in advance how much we will need.  I hope Handa-san could explain.

> If the malloc/free done for this encode/decode is relatively costly,
> maybe it's because we allocate too much space compared to what we use.

Again, the problem is memory fragmentation and the resulting large
footprint, not the cost of the allocation.