[Top][All Lists]

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

Re: eval proposals

From: Stefan Monnier
Subject: Re: eval proposals
Date: Fri, 06 Jun 2014 12:58:26 -0400
User-agent: 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
  from 83200000.
- max-lisp-eval-depth defaults to 600 IIRC, which is pretty damn very far
  from 640000.
- Your example runs out of C stack, so it doesn't work anyway.


reply via email to

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