Re: Enlarge MAX_ALLOCA?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > 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?

OK.

>> >> 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 see, so it's not just hypothetical (tho the evidence is
circumstantial, as is usually the case: proving fragmentation is
difficult).

So I think the way to go is the following:
- see if we can allocate this area less frequently (e.g. if it's for
  handling compositions, it seems like it shouldn't be needed in your
  cases where you encode file names (or do your file names have parts
  that require compositions?)).  I.e. delay the allocation to when we
  really need it.
- try to reduce the size of this area.
- if the above two is not sufficient, try and just use plain `alloca'
  (tho the "delay allocation" part above might make it
  difficult/impossible to use alloca).

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

Try to put him closer to the other 2 systems, so he'll feel ashamed.


        Stefan