Subject: bug#78898: Make read/readevalloop reentrant

From: Lynn Winebarger <[email-masked]>
Date: Mon, 21 Jul 2025 11:29:36 -0400

On Sat, Jul 5, 2025, 6:13 AM Mattias Engdegård <[email-masked]>
wrote:

> 28 juni 2025 kl. 12.08 skrev Eli Zaretskii <[email-masked]>:
>
> > Do we really want readevalloop be recursive this way?  What does this
> > gain us?
>
> In principle there should be no reason for readevalloop being
> non-reentrant at all and remedying this should be an obvious improvement,
> but I cannot give a concrete example of how it would benefit us immediately.
>
> That said, I think the approach here is a bit too much at once; I'd rather
> nibble away at state a little at a time since much of lread.c is messy
> legacy code.

For my next increment, I want to try managing the read stack with alloca
and friends.  The way it is now, memory allocated for that stack is never
recovered.

I also tried eliminating base_sp from read0, but it failed. IOW, read0 is
getting recursively invoked in the middle of reading an expression.  So the
size of the read stack may not be bounded by the maximum depth of a single
expression.  I want to measure what's going on there.

Also, I'd like some concrete cases for measuring the impact of the reader
performance on emacs startup.  When I look at the profiles of the dump
recipes, the time spent in lread.c is tiny compared to evaluating the code
being read, even when loading byte-compiled code.

Lynn