Re: Enlarge MAX_ALLOCA?

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Thu, 19 Jun 2014 18:23:26 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> > -#define SAFE_ALLOCA(size) ((size) < MAX_ALLOCA    \
>> > +#define SAFE_ALLOCA(size) ((size) <= MAX_ALLOCA   \
>> >                       ? alloca (size)      \
>> >                       : (sa_must_free = true, record_xmalloc (size)))
>> >  
>> > @@ -4469,7 +4469,7 @@ extern void *record_xmalloc (size_t) ATT
>> >  
>> >  #define SAFE_ALLOCA_LISP(buf, nelt)                              \
>> >    do {                                                           \
>> > -    if ((nelt) < MAX_ALLOCA / word_size)                 \
>> > +    if ((nelt) <= MAX_ALLOCA / word_size)                \
>> >        (buf) = alloca ((nelt) * word_size);                       \
>> >      else if ((nelt) < min (PTRDIFF_MAX, SIZE_MAX) / word_size) \
>> >        {                                                          \
>> 
>> Bad idea to change < to <= here.
>
> The original macros were inconsistent: some used < and some <=, so I
> changed them.
>
>> If there is a hard limit due to short offsets or similar (and if
>> there weren't, why bother at all?), then allocating a full 64kB
>> might be a bad idea.
>
> Is there really such a system?  If so, which one?

Either your limit has a rationale in machine architectures or not.  If
it has: the C standard guarantees that you are allowed to take the
address _after_ an array.

The 68k architecture has short offsets (-32768..+32767) for addressing
off an address register such as the stack pointer.

> And why would that be a worse idea than to allocate the same 64KB off
> the heap (which is what that macro does in the 'else' clause?  What am
> I missing?

Heap addressing will not employ short offsets/pointers on such
architectures.

>> 64kB feels arbitrary.
>
> I explained my rationale for choosing this value.

The explanation was:

> Why 64KB?  Because that's the size of the work area coding.c allocates
> whenever it needs to encode or decode something.  It turns out we do
> this a lot, e.g., every redisplay calls file-readable-p on the icon
> image files, which needs to encode the file name.  While the work area
> is immediately free'd, I think allocating such a large buffer so much
> has a potential of creating an unnecessary memory pressure on
> 'malloc', and perhaps cause excess fragmentation and/or enlarge memory
> footprint in some cases.

That's not related to an architecture restraint.  In fact, it merely
follows the arbitrary definition

#define CHARBUF_SIZE 0x4000

Arbitrary because this is not a lookup table size but a buffer size for
portioned conversion.  Instead of doubling MAX_ALLOCA, it would seem to
make more sense to reduce CHARBUF_SIZE to something making it fit better
on the stack if this is performance relevant.

As I said: there are architectural reasons (short addressing mode)
making somewhat less than 32kB a good choice on some architectures.

-- 
David Kastrup