GNU bug report logs - #57911
Abolish max-specpdl-size

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#57911: closed (Abolish max-specpdl-size)
Date: Mon, 19 Sep 2022 17:38:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 19 Sep 2022 19:36:51 +0200
with message-id <33AB9E98-2B0C-46AD-A1F0-5A13978DEBAA <at> gmail.com>
and subject line Re: bug#57911: Abolish max-specpdl-size
has caused the debbugs.gnu.org bug report #57911,
regarding Abolish max-specpdl-size
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
57911: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57911
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Subject: Abolish max-specpdl-size
Date: Sun, 18 Sep 2022 13:57:22 +0200

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.

[Message part 3 (message/rfc822, inline)]

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57911-done <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#57911: Abolish max-specpdl-size
Date: Mon, 19 Sep 2022 19:36:51 +0200

19 sep. 2022 kl. 15.54 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> And I take from Stefan's
>> response that he has no objections...  Eli, any comments?
> 
> No.

Thank you, pushed to master and closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.