From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org,
eller.helmut@gmail.com, acorallo@gnu.org
Subject: Re: Some experience with the igc branch
Date: Wed, 25 Dec 2024 16:37:47 +0200 [thread overview]
Message-ID: <864j2r25hg.fsf@gnu.org> (raw)
In-Reply-To: <m2wmfnan97.fsf@gmail.com> (message from Gerd Möllmann on Wed, 25 Dec 2024 14:46:44 +0100)
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org,
> eller.helmut@gmail.com, acorallo@gnu.org
> Date: Wed, 25 Dec 2024 14:46:44 +0100
>
> Roots: There are GC roots in the old GC. Specpdl stacks are roots,
> DEFVARs, control stacks, DEFSYM symbols, the bytecode stacks and so on.
> They are marked first at the beginning of GC. The roots and everything
> recursively reachable from them are all live objects.
>
> Roots in igc are basically the same thing. There are MPS function with
> which one can define roots, if you mean that by "what it means in
> practice". These MPS functions are called in igc.c. Please don't ask
> which functions :-).
>
> alloc_impl: This function is used for the allocation of all Lisp
> objects, vectors, strings, frames, everything that can end up being
> references as Lisp_Object. So everything except fixnums. And it is not
> used to allocate other stuff, the xmalloc family of functions is used
> for that.
OK, thanks.
So there are Lisp objects allocated by alloc_impl, roots allocated
via MPS, and data allocated by xmalloc that MPS doesn't know about, is
that correct?
> > Once again, I think this is very important for future maintenance. I
> > feel that this barrier thing in MPS introduces significant
> > complications into reasoning about safety of C-level changes.
> > Previously, we only had the mark bit to worry about if we wanted to
> > access Lisp objects during GC (see gc_asize, for example), but now we
> > have a much larger problem, AFAIU. How do we manage that for the next
> > 40 years?
>
> These problems do not exist. The barriers are transparent for the
> application, except in vary special circumstances, namely this shit
> signal handler.
But I _am_ talking about this "shit signal handler". I'm trying to
understand how would I go about reasoning whether accessing specpdl
from the signal handler is okay. Is that because I'm supposed to know
that the specpdl stack is a root? If so, I'd need to figure out that
for every datum the handler accesses, no?
I guess I'm yearning for some commentary in igc.c, not unlike what you
wrote in xdisp.c at the time, which would explain the basics, like
what are roots, what's the purpose of all those root_create_SOMETHING
functions, what's the difference between exact and ambiguous roots,
etc. Because currently we are not too spoiled by comments in igc.c.
next prev parent reply other threads:[~2024-12-25 14:37 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-22 15:40 Some experience with the igc branch Óscar Fuentes
2024-12-22 17:18 ` Gerd Möllmann
2024-12-22 17:29 ` Gerd Möllmann
2024-12-22 17:41 ` Pip Cet via Emacs development discussions.
2024-12-22 17:56 ` Gerd Möllmann
2024-12-22 19:11 ` Óscar Fuentes
2024-12-23 0:05 ` Pip Cet via Emacs development discussions.
2024-12-23 1:00 ` Óscar Fuentes
2024-12-24 22:34 ` Pip Cet via Emacs development discussions.
2024-12-25 4:25 ` Freezing frame with igc Gerd Möllmann
2024-12-25 11:19 ` Pip Cet via Emacs development discussions.
2024-12-25 11:55 ` Óscar Fuentes
2024-12-23 3:42 ` Some experience with the igc branch Gerd Möllmann
2024-12-23 6:27 ` Jean Louis
2024-12-22 20:29 ` Helmut Eller
2024-12-22 20:50 ` Gerd Möllmann
2024-12-22 22:26 ` Pip Cet via Emacs development discussions.
2024-12-23 3:23 ` Gerd Möllmann
[not found] ` <m234ieddeu.fsf_-_@gmail.com>
[not found] ` <87ttaueqp9.fsf@protonmail.com>
[not found] ` <m2frme921u.fsf@gmail.com>
[not found] ` <87ldw6ejkv.fsf@protonmail.com>
[not found] ` <m2bjx2h8dh.fsf@gmail.com>
2024-12-23 14:45 ` Make Signal handling patch platform-dependent? Pip Cet via Emacs development discussions.
2024-12-23 14:54 ` Gerd Möllmann
2024-12-23 15:11 ` Eli Zaretskii
2024-12-23 13:35 ` Some experience with the igc branch Eli Zaretskii
2024-12-23 14:03 ` Discussion with MPS people Gerd Möllmann
2024-12-23 14:04 ` Gerd Möllmann
2024-12-23 15:07 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-23 15:26 ` Gerd Möllmann
2024-12-23 16:03 ` Pip Cet via Emacs development discussions.
2024-12-23 16:44 ` Eli Zaretskii
2024-12-23 17:16 ` Pip Cet via Emacs development discussions.
2024-12-23 18:35 ` Eli Zaretskii
2024-12-23 18:48 ` Gerd Möllmann
2024-12-23 19:25 ` Eli Zaretskii
2024-12-23 20:30 ` Benjamin Riefenstahl
2024-12-23 23:39 ` Pip Cet via Emacs development discussions.
2024-12-24 12:14 ` Eli Zaretskii
2024-12-24 13:18 ` Pip Cet via Emacs development discussions.
2024-12-24 13:42 ` Benjamin Riefenstahl
2024-12-24 3:37 ` Eli Zaretskii
2024-12-24 8:48 ` Benjamin Riefenstahl
2024-12-24 13:52 ` Eli Zaretskii
2024-12-24 13:54 ` Benjamin Riefenstahl
2024-12-23 17:44 ` Gerd Möllmann
2024-12-23 19:00 ` Eli Zaretskii
2024-12-23 19:37 ` Eli Zaretskii
2024-12-23 20:49 ` Gerd Möllmann
2024-12-23 21:43 ` Helmut Eller
2024-12-23 21:49 ` Pip Cet via Emacs development discussions.
2024-12-23 21:58 ` Helmut Eller
2024-12-23 23:20 ` Pip Cet via Emacs development discussions.
2024-12-24 5:38 ` Helmut Eller
2024-12-24 6:27 ` Gerd Möllmann
2024-12-24 10:09 ` Pip Cet via Emacs development discussions.
2024-12-24 4:05 ` Gerd Möllmann
2024-12-24 8:50 ` Gerd Möllmann
2024-12-24 6:03 ` SIGPROF + SIGCHLD and igc Gerd Möllmann
2024-12-24 8:23 ` Helmut Eller
2024-12-24 8:39 ` Gerd Möllmann
2024-12-25 9:22 ` Helmut Eller
2024-12-25 9:43 ` Gerd Möllmann
2024-12-24 13:05 ` Eli Zaretskii
2024-12-25 10:46 ` Helmut Eller
2024-12-25 12:45 ` Eli Zaretskii
2024-12-24 12:54 ` Eli Zaretskii
2024-12-24 12:59 ` Gerd Möllmann
2024-12-23 23:37 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-24 4:03 ` Gerd Möllmann
2024-12-24 10:25 ` Pip Cet via Emacs development discussions.
2024-12-24 10:50 ` Gerd Möllmann
2024-12-24 13:15 ` Eli Zaretskii
2024-12-24 12:26 ` Eli Zaretskii
2024-12-24 12:56 ` Gerd Möllmann
2024-12-24 13:19 ` Pip Cet via Emacs development discussions.
2024-12-24 13:38 ` Gerd Möllmann
2024-12-24 13:46 ` Eli Zaretskii
2024-12-24 14:12 ` Gerd Möllmann
2024-12-24 14:40 ` Eli Zaretskii
2024-12-25 4:56 ` Gerd Möllmann
2024-12-25 12:19 ` Eli Zaretskii
2024-12-25 12:50 ` Gerd Möllmann
2024-12-25 13:00 ` Eli Zaretskii
2024-12-25 13:08 ` Gerd Möllmann
2024-12-25 13:26 ` Eli Zaretskii
2024-12-25 14:07 ` Gerd Möllmann
2024-12-25 14:43 ` Helmut Eller
2024-12-25 14:59 ` Eli Zaretskii
2024-12-25 20:44 ` Helmut Eller
2024-12-26 6:29 ` Eli Zaretskii
2024-12-26 8:02 ` Helmut Eller
2024-12-26 9:32 ` Eli Zaretskii
2024-12-25 15:02 ` Gerd Möllmann
2024-12-25 13:09 ` Eli Zaretskii
2024-12-25 13:46 ` Gerd Möllmann
2024-12-25 14:37 ` Eli Zaretskii [this message]
2024-12-25 14:57 ` Gerd Möllmann
2024-12-25 15:28 ` Eli Zaretskii
2024-12-25 15:49 ` Gerd Möllmann
2024-12-25 17:26 ` Eli Zaretskii
2024-12-26 5:25 ` Gerd Möllmann
2024-12-26 7:43 ` Eli Zaretskii
2024-12-26 7:57 ` Gerd Möllmann
2024-12-25 17:40 ` Pip Cet via Emacs development discussions.
2024-12-25 17:51 ` Eli Zaretskii
2024-12-26 5:27 ` Gerd Möllmann
2024-12-26 5:29 ` Gerd Möllmann
2024-12-24 21:18 ` Pip Cet via Emacs development discussions.
2024-12-25 5:23 ` Gerd Möllmann
2024-12-25 10:48 ` Pip Cet via Emacs development discussions.
2024-12-25 13:40 ` Stefan Kangas
2024-12-25 17:03 ` Pip Cet via Emacs development discussions.
2024-12-26 5:22 ` Gerd Möllmann
2024-12-26 7:33 ` Eli Zaretskii
2024-12-26 8:02 ` Gerd Möllmann
2024-12-25 11:48 ` Helmut Eller
2024-12-25 11:58 ` Gerd Möllmann
2024-12-25 12:52 ` Eli Zaretskii
2024-12-25 12:31 ` Eli Zaretskii
2024-12-25 12:54 ` Gerd Möllmann
2024-12-24 12:11 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=864j2r25hg.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acorallo@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=ofv@wanadoo.es \
--cc=pipcet@protonmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.