On 23. Jun 2022, 08:58 +0200, Eli Zaretskii <eliz@gnu.org>, wrote:
Do you want to do that or should I?
Feel free to do it, I generally prefer that people who see the problem
and could at least potentially test the solution also make the change
to fix it.
Ok
Another side question, if I may: Have you perhaps heard of someone producing a static call graph for
Emacs, or better yet, specific functions in Emacs? Maybe using objdump -D or something similar?
Does this make sense in a dynamic program such as Emacs? We call into
Lisp quite a lot from C, and from there you can arrive anywhere, no?
And objdump cannot capture Lisp levels.
True, but for GC at least, I think it would make it easier to tell if it can potentially happen. One would see a call to GC in the static call graph. Not for arbitrary lines, of course, you know what I mean...
That is, btw, the main problem with maintaining Emacs internals
nowadays: it is hard, almost impossible, to know, just by looking at C
code, whether GC or any other Lisp-related activity could happen
between two arbitrary lines of C. We have more and more hooks called
from C that could potentially call any Lisp, and we have more and more
direct calls into Lisp from the most intimate parts of Emacs, like the
display engine and the main loop in keyboard.c. This basically makes
any analysis of whether or not some code fragment could cause GC
futile: even if today it's impossible, it can easily become possible
tomorrow, with some innocent-looking change. This is exacerbated by
the fact that GCPROs are long gone, so the caution we used to
exercised 20 years ago to make sure GC doesn't surprise us is no
longer needed nor practiced.
All true, I just want to remark that I have no fond memories of GCPRO, and of debugging stuff caused by missing ones. Glad to hear they're finally completely dead now.
But no, I don't think anyone tried to see what kind of graph could be
obtained. Maybe it's worthwhile, who knows? we might learn something
useful regardless.
Thanks