Re: Enlarge MAX_ALLOCA?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: handa@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 20 Jun 2014 09:02:19 -0400
> 
> > Alternatively, how about using a different limit just in the 2 users
> > of ALLOC_CONVERSION_WORK_AREA?
> 
> Why not just use `alloca' directly for those cases, then?

With an assertion in case the size is enlarged some day?

> >> 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.
> 
> I'd expect any non-toy implementation of malloc/free to handle this
> without any serious risk of fragmentation, to tell you the truth.

gmalloc doesn't, at least not with ralloc.c.  One of my systems keeps
growing in memory, and the only reason I could find is these constant
allocations.  I don't know whether it's fragmentation or not, but the
fact is, once every few dozens of such calls, sbrk gets called to
enlarge the brk value.  Whenever sbrk is called, I always see
ALLOC_CONVERSION_WORK_AREA on the callstack asking for the same 64KB
allocation.  The higher-level code that triggers that is either
file-readable-p test for a tool-bar icon, or current-time-zone (called
frequently because I customized display-time to update the mode line
every 5 sec).

It could be that this is due to the known problems with ralloc.c,
whereby it sometimes loses track of some bloc it manages, and then all
the blocs below that become "trapped" and cannot be relinquished back
to the system.  I plan to try this with the trunk version soon, where
ralloc is no longer used.

Strange thing is, this only happens on 1 of 3 systems I use regularly,
which all have almost identical setup.