GNU bug report logs - #76180
[feature/igc] Remaining known tracing issues

Previous Next

Full log

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 bug-gnu-emacs <at> gnu.org, Andrea Corallo <acorallo <at> gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: [feature/igc] Remaining known tracing issues
Date: Tue, 11 Feb 2025 07:14:55 +0100

Pip Cet <pipcet <at> protonmail.com> writes:

> 1. Bytecode objects violating the stack limit prosaically called
> HORRIBLE_ESTIMATE will fail to scan some of their excessively-large
> bytecode stack if interrupted by GC in execution.

The current bytecode stack design is not really my thing, TBH. But I
haven't followed what has been happening the last decades, so what do I
know.

There were times back then when I allocated byte code stacks using
alloca for each frame, which of course implies that the maximum stack
size was known at the time. (The idea behind that was to use
conservative stack marking and so on.)

Why that isn't the case now, I don't know. Or maybe I just didn't find
it. Also, I'm not sure if that is still the case, but it might be worth
checking if an overflow of the large stacks that are currently used
(500K or so) is detected.

Previous Next

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