[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eval proposals
Re: eval proposals
Fri, 06 Jun 2014 12:58:26 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
> 1) Protection against C stack overflow caused by enormously huge
> `max-lisp-eval-depth'. Note that the stack size limit is examined
> just once (because doing it each time when eval_sub or funcall is
> called introduces too much overhead), but some OSes are capable to
> change this limit when the program is running (prlimit on Linux,
> for example).
max-lisp-eval-depth exists in large part in order to avoid such stack
overflows, so if we do like you suggest, we might want to get rid
of max-lisp-eval-depth (tho this would have the disadvantage that
infinite-recursion would get caught much later).
Also we want some way to get into the debugger when hitting that error,
which requires more stack space.
Doing both max-lisp-eval-depth and stack_guard at every eval_sub and
Ffuncall sounds too costly.
Maybe a better mechanism would be one that checks the value of
max-lisp-eval-depth (which only needs to be done when max-lisp-eval-depth
changes, which is very rare). Of course, the correlation between
lisp_eval_depth and actual stack depth is not perfect, but it should be
good enough if we include enough fudge factor.
> 2) Capability to shrink specpdl stack if it becomes too large.
> When `max-specpdl-size' is 83200000 and `max-lisp-eval-depth' is
> 640000, this extreme example with 10K let bindings:
> (defun f ()
> (let ((x0 0)
> (x1 1)
> (x9999 9999)) (f)))
> creates 73622255-slots specpdl stack before running out of C stack
> on my system, which results in 2.5G RSS. And currently there is no
> way to reduce it back to reasonable size.
I'm not necessarily opposed to shrinking the specpdl, but this example
is *really* not compelling:
- The code doesn't look like anything I've seen.
- max-specpdl-size defaults to 1300, IIRC, which is pretty damn very far
- max-lisp-eval-depth defaults to 600 IIRC, which is pretty damn very far
- Your example runs out of C stack, so it doesn't work anyway.