From: "Mattias Engdegård" <mattias.engdegard@gmail.com>
To: 57911@debbugs.gnu.org
Subject: bug#57911: Abolish max-specpdl-size
Date: Sun, 18 Sep 2022 13:57:22 +0200 [thread overview]
Message-ID: <02FBC80B-A05B-4384-B442-B1FB9F70CA05@gmail.com> (raw)
This is a proposal to abolish max-specpdl-size, the user-controllable limit on the internal specpdl stack.
It is safe to do so because unbounded specpdl growth is not possible without proportionally growing the lisp-eval-depth. Therefore, max-lisp-eval-depth suffices as a guard against runaway recursion and unreasonable memory usage as it effectively bounds the specpdl stack as well.
The change would give us some performance benefits but the biggest gain is in user convenience: currently, any code that needs deeper recursion than permitted by default has to set two variables. What values to use is often a matter of puzzlement and guessing since it is far from clear to anyone how they relate.
Why abolish max-specpdl-size rather than max-lisp-eval-depth, if they are connected? First and foremost, because the lisp-eval-depth is easier to explain and understand; the specpdl is an internal implementation detail that most Lisp users don't really have a firm grip on.
Moreover, although each Lisp call currently consumes at least one specpdl entry, this won't necessarily remain true in the future: it should be possible to eliminate that specpdl usage for gains in both speed and memory. In that case, max-specpdl-size would no longer serve as an effective recursion limit.
Concretely, the change would amount to retaining max-specpdl-size as a plain dynamic Lisp variable with no special meaning. We could obsolete it or keep it around indefinitely. A patch will come -- it's all very straightforward.
next reply other threads:[~2022-09-18 11:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 11:57 Mattias Engdegård [this message]
2022-09-19 7:10 ` bug#57911: Abolish max-specpdl-size Lars Ingebrigtsen
2022-09-19 9:35 ` Mattias Engdegård
2022-09-19 12:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-19 15:35 ` Mattias Engdegård
2022-09-19 16:52 ` Michael Albinus
2022-09-19 17:09 ` Lars Ingebrigtsen
2022-09-19 17:30 ` Michael Albinus
2022-09-19 18:25 ` Lars Ingebrigtsen
2022-09-20 12:23 ` Visuwesh
2022-09-20 15:52 ` Eli Zaretskii
2022-09-20 16:23 ` Visuwesh
2022-09-20 16:30 ` Eli Zaretskii
2022-09-20 16:30 ` Lars Ingebrigtsen
2022-09-20 16:36 ` Eli Zaretskii
2022-09-20 16:48 ` Lars Ingebrigtsen
2022-09-20 17:27 ` Eli Zaretskii
2022-09-21 11:04 ` Lars Ingebrigtsen
2022-09-20 21:51 ` Gregory Heytings
2022-09-20 20:32 ` Lars Ingebrigtsen
2022-09-21 0:02 ` Gregory Heytings
2022-09-19 17:28 ` Mattias Engdegård
2022-09-19 12:40 ` Lars Ingebrigtsen
2022-09-19 13:54 ` Eli Zaretskii
2022-09-19 17:36 ` Mattias Engdegård
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02FBC80B-A05B-4384-B442-B1FB9F70CA05@gmail.com \
--to=mattias.engdegard@gmail.com \
--cc=57911@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).