; * src/lisp.h (MAX_ALLOCA): Comment on enlarging the value.
This commit is contained in:
parent
b5c290cfbd
commit
55d4596dd0
1 changed files with 15 additions and 1 deletions
16
src/lisp.h
16
src/lisp.h
|
|
@ -5616,7 +5616,21 @@ extern void init_system_name (void);
|
|||
#define eabs(x) ((x) < 0 ? -(x) : (x))
|
||||
|
||||
/* SAFE_ALLOCA normally allocates memory on the stack, but if size is
|
||||
larger than MAX_ALLOCA, use xmalloc to avoid overflowing the stack. */
|
||||
larger than MAX_ALLOCA, use xmalloc to avoid overflowing the stack.
|
||||
|
||||
If you are thinking MAX_ALLOCA is too small given the usual C stack
|
||||
size of programs on modern platforms, consider the following adverse
|
||||
effects of allowing larger stack-based allocations:
|
||||
|
||||
. Conservative stack scanning by GC is expensive; enlarging the
|
||||
stack will force GC to scan more, and thus GC cycles will take
|
||||
more time.
|
||||
. A large stack-based allocation risks to miss the guard page at
|
||||
the end of the stack space, which is used by modern operating
|
||||
systems to detect stack exhaustion and enlarge the stack as
|
||||
needed; this thus risks hitting a segfault where none should
|
||||
have happened. (This problem is real in deeply-recursive cases,
|
||||
but these do happen in Emacs, e.g. in regexp search or during GC.) */
|
||||
|
||||
enum MAX_ALLOCA { MAX_ALLOCA = 16 * 1024 };
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue