[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enlarge MAX_ALLOCA?
From: |
Stefan Monnier |
Subject: |
Re: Enlarge MAX_ALLOCA? |
Date: |
Thu, 19 Jun 2014 16:37:07 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
>> 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 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 hope Handa-san could explain.
Handa?
> 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?
Stefan
Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/19
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/19
- Re: Enlarge MAX_ALLOCA?,
Stefan Monnier <=
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- RE: Enlarge MAX_ALLOCA?, Herring, Davis, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Dmitry Antipov, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
Re: Enlarge MAX_ALLOCA?, K. Handa, 2014/06/21
Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/21