Re: Enlarge MAX_ALLOCA?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Kenichi Handa <handa@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 19 Jun 2014 16:37:07 -0400
> 
> >> 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?
> 
> I don't know.  Maybe none, but that would surprise me.

I will take a look.

Alternatively, how about using a different limit just in the 2 users
of ALLOC_CONVERSION_WORK_AREA?

> >> 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 why.  Perhaps it's hard to
> > know in advance how much we will need.
> 
> Supposedly, every coding system comes with a "blow up factor" (can't
> remember the name we use) which should be usable to compute a safe
> upper-bound.

I don't think the work area is what you think it is.  It is not for
the result of the encoding/decoding; that is allocated elsewhere, and
indeed uses a dynamic size computed from the source size.  This work
area is for something else: for handling composition annotations
(whatever that is).  See handle_composition_annotation and
produce_annotation in coding.c.

> > Again, the problem is memory fragmentation and the resulting large
> > footprint, not the cost of the allocation.
> 
> Is this memory fragmentation problem hypothetical, or have we seen
> evidence of it?

Hypothetical.  I just don't like seeing such frequent sequences of
malloc(64K)/free() one after the other several times a second in a
live session.