[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enlarge MAX_ALLOCA?

From: Eli Zaretskii
Subject: Re: Enlarge MAX_ALLOCA?
Date: Thu, 19 Jun 2014 21:38:40 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]