* Not protecting Lisp objects from GC
@ 2025-01-27 9:08 Gerd Möllmann
2025-01-27 9:46 ` Stefan Kangas
` (2 more replies)
0 siblings, 3 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 9:08 UTC (permalink / raw)
To: Emacs Devel
I've just noticed the latest commit in the igc branch, which adds to the
comment of DEFVAR_LISP_NOPRO, and together with what I've seen in other
discussions, I feel I have to say something.
I'm talking about the old GC, and it is _bad_ to not protect GC'able
objects because
- they are protected from GC by being referenced from other objects that
we '"know" are protected from GC
- because a GC "cannot happen"
And there are _no_ exceptions.
I'm speaking as a software engineer with decades of experience in
commercial software projects, and also from my experience as Emacs'
maintainer. Back then, even local variables had to be protected from GC
with a macro named GCPRO. And that was used in many places making
exactly the above assumptions.
I called that "aggressive use of GCPRO".
Aggressive because it's unmaintainable. I cannot possibly describe what
a debugging nightmare it was when the assumptions were no longer true
and some GCPRO was now missing because of innocent changes kilometers
away in a call tree.
And now I see the same assumptions being made in other circumstances,
and it seems nothing has ever been learned.
Anyone, please stop doing this. It's *BAD*.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 9:08 Not protecting Lisp objects from GC Gerd Möllmann
@ 2025-01-27 9:46 ` Stefan Kangas
2025-01-27 13:11 ` Eli Zaretskii
2025-01-27 13:01 ` Eli Zaretskii
2025-02-03 19:24 ` Pip Cet via Emacs development discussions.
2 siblings, 1 reply; 76+ messages in thread
From: Stefan Kangas @ 2025-01-27 9:46 UTC (permalink / raw)
To: Gerd Möllmann, Emacs Devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> I've just noticed the latest commit in the igc branch, which adds to the
> comment of DEFVAR_LISP_NOPRO, and together with what I've seen in other
> discussions, I feel I have to say something.
>
> I'm talking about the old GC, and it is _bad_ to not protect GC'able
> objects because
>
> - they are protected from GC by being referenced from other objects that
> we '"know" are protected from GC
>
> - because a GC "cannot happen"
>
> And there are _no_ exceptions.
>
> I'm speaking as a software engineer with decades of experience in
> commercial software projects, and also from my experience as Emacs'
> maintainer. Back then, even local variables had to be protected from GC
> with a macro named GCPRO. And that was used in many places making
> exactly the above assumptions.
>
> I called that "aggressive use of GCPRO".
>
> Aggressive because it's unmaintainable. I cannot possibly describe what
> a debugging nightmare it was when the assumptions were no longer true
> and some GCPRO was now missing because of innocent changes kilometers
> away in a call tree.
>
> And now I see the same assumptions being made in other circumstances,
> and it seems nothing has ever been learned.
>
> Anyone, please stop doing this. It's *BAD*.
As I said in Bug#75521, I'll reiterate here for the record: I believe we
should remove DEFVAR_LISP_NOPRO and avoid pursuing these kinds of
optimizations.
Additionally, the comment in font.c about "wasting slots" in staticvec
seems misleading. There's plenty of free space in staticvec, and adding
three more elements is quite unlikely to have any significant impact on
paging behavior.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 9:08 Not protecting Lisp objects from GC Gerd Möllmann
2025-01-27 9:46 ` Stefan Kangas
@ 2025-01-27 13:01 ` Eli Zaretskii
2025-01-27 13:26 ` Gerd Möllmann
2025-02-03 19:24 ` Pip Cet via Emacs development discussions.
2 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 13:01 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Mon, 27 Jan 2025 10:08:17 +0100
>
> I've just noticed the latest commit in the igc branch, which adds to the
> comment of DEFVAR_LISP_NOPRO, and together with what I've seen in other
> discussions, I feel I have to say something.
>
> I'm talking about the old GC, and it is _bad_ to not protect GC'able
> objects because
>
> - they are protected from GC by being referenced from other objects that
> we '"know" are protected from GC
>
> - because a GC "cannot happen"
>
> And there are _no_ exceptions.
>
> I'm speaking as a software engineer with decades of experience in
> commercial software projects, and also from my experience as Emacs'
> maintainer. Back then, even local variables had to be protected from GC
> with a macro named GCPRO. And that was used in many places making
> exactly the above assumptions.
>
> I called that "aggressive use of GCPRO".
>
> Aggressive because it's unmaintainable. I cannot possibly describe what
> a debugging nightmare it was when the assumptions were no longer true
> and some GCPRO was now missing because of innocent changes kilometers
> away in a call tree.
>
> And now I see the same assumptions being made in other circumstances,
> and it seems nothing has ever been learned.
>
> Anyone, please stop doing this. It's *BAD*.
Gerd,
No one is disagreeing with you, at least not IMO. I'm not aware of
any code we added lately that consciously avoids GC-protecting data
which should be protected. We may have existing code which does that,
yes, and when we find it, we generally try to plug those holes,
especially on the igc branch, where we sometimes find that what didn't
have to be protected before must be protected now. But we don't add
any new code under such incorrect assumptions.
As for the offending commit, it just added a description of the
purpose of DEFVAR_LISP_NOPRO and how it is currently used, that's all.
It didn't suggest to use it more or anything like that.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 9:46 ` Stefan Kangas
@ 2025-01-27 13:11 ` Eli Zaretskii
2025-01-27 13:45 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 13:11 UTC (permalink / raw)
To: Stefan Kangas; +Cc: gerd.moellmann, emacs-devel
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 27 Jan 2025 03:46:21 -0600
>
> As I said in Bug#75521, I'll reiterate here for the record: I believe we
> should remove DEFVAR_LISP_NOPRO and avoid pursuing these kinds of
> optimizations.
And as I said in that bug's discussion, I'm not interested in
improving the old GC where the existing code works well and is not
understood very well by the active maintainers. Let's instead invest
our energy in making the igc branch (where DEFVAR_LISP_NOPRO is not
used) stable sooner so we could merge it.
> Additionally, the comment in font.c about "wasting slots" in staticvec
> seems misleading. There's plenty of free space in staticvec, and adding
> three more elements is quite unlikely to have any significant impact on
> paging behavior.
See above.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 13:01 ` Eli Zaretskii
@ 2025-01-27 13:26 ` Gerd Möllmann
2025-01-27 14:00 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 13:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Anyone, please stop doing this. It's *BAD*.
>
> Gerd,
>
> No one is disagreeing with you, at least not IMO.
That's good to hear, thanks.
> I'm not aware of any code we added lately that consciously avoids
> GC-protecting data which should be protected. We may have existing
> code which does that, yes, and when we find it, we generally try to
> plug those holes,
The comment you added mentions a case where DEFVAR_LISP_NOPRO is used in
exactly the way I described. That needs to be fixed! Just adding a
comment is accepting it, and is worse than as writing such code in the
first place. The old GC won't go away for many years.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 13:11 ` Eli Zaretskii
@ 2025-01-27 13:45 ` Gerd Möllmann
0 siblings, 0 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 13:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Kangas, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Mon, 27 Jan 2025 03:46:21 -0600
>>
>> As I said in Bug#75521, I'll reiterate here for the record: I believe we
>> should remove DEFVAR_LISP_NOPRO and avoid pursuing these kinds of
>> optimizations.
>
> And as I said in that bug's discussion, I'm not interested in
> improving the old GC where the existing code works well and is not
> understood very well by the active maintainers.
The effects and unmaintainability of what I referred to it very well
known. One doesn't have to be a rocket engineer to fix these cases.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 13:26 ` Gerd Möllmann
@ 2025-01-27 14:00 ` Eli Zaretskii
2025-01-27 14:18 ` Gerd Möllmann
2025-01-27 17:46 ` Stefan Kangas
0 siblings, 2 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 14:00 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 14:26:42 +0100
>
> The comment you added mentions a case where DEFVAR_LISP_NOPRO is used in
> exactly the way I described. That needs to be fixed!
AFAIU, we've fixed that already on the igc branch, in the MPS build,
in the sense that this macro was effectively removed in favor of
DEFVAR_LISP. So when the igc branch lands, we will have that solved
on master, when building with MPS (which I hope will be what most of
the supported platforms will use).
In the non-MPS build, the changes which were proposed to remove its
use messed with special-purpose code in a way that I felt uneasy with,
so I preferred to leave the existing code alone. I have my share of
gray hair from making changes in font.c and fontset.c. If someone
suggests a simpler, cleaner change, I might reconsider.
> Just adding a comment is accepting it, and is worse than as writing
> such code in the first place.
Sorry, I fail to understand how describing some existing code could be
bad. "Security by obscurity" doesn't really work, as we all know, and
maintainers have to deal with code that they don't like every day, so
helping them understand tricky corners cannot be bad, IMO.
> The old GC won't go away for many years.
Maybe not, but then the code in question worked for us for decades, so
a probability of a serious error there is quite low, to say the least.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 14:00 ` Eli Zaretskii
@ 2025-01-27 14:18 ` Gerd Möllmann
2025-01-27 15:10 ` Eli Zaretskii
2025-01-27 17:46 ` Stefan Kangas
1 sibling, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 14:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 27 Jan 2025 14:26:42 +0100
>>
>> The comment you added mentions a case where DEFVAR_LISP_NOPRO is used in
>> exactly the way I described. That needs to be fixed!
>
> AFAIU, we've fixed that already on the igc branch, in the MPS build,
These things obviously need to be fixed on master when they are found.
It has nothing to do with igc.
> in the sense that this macro was effectively removed in favor of
> DEFVAR_LISP. So when the igc branch lands, we will have that solved
> on master, when building with MPS (which I hope will be what most of
> the supported platforms will use).
>
> In the non-MPS build, the changes which were proposed to remove its
> use messed with special-purpose code in a way that I felt uneasy with,
> so I preferred to leave the existing code alone. I have my share of
> gray hair from making changes in font.c and fontset.c. If someone
> suggests a simpler, cleaner change, I might reconsider.
>
>> Just adding a comment is accepting it, and is worse than as writing
>> such code in the first place.
>
> Sorry, I fail to understand how describing some existing code could be
> bad. "Security by obscurity" doesn't really work, as we all know, and
> maintainers have to deal with code that they don't like every day, so
> helping them understand tricky corners cannot be bad, IMO.
>
>> The old GC won't go away for many years.
>
> Maybe not, but then the code in question worked for us for decades, so
> a probability of a serious error there is quite low, to say the least.
What you are doing is not fixing obvious maintainability bugs which
might also show up as real bugs in production. You are writing comments
instead. In another branch. And from what I read so far, I get the
impression that you are objecting to others making the fixes, in that
branch.
Not sure what I should think about this.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 14:18 ` Gerd Möllmann
@ 2025-01-27 15:10 ` Eli Zaretskii
2025-01-27 15:27 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 15:10 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 15:18:25 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Sorry, I fail to understand how describing some existing code could be
> > bad. "Security by obscurity" doesn't really work, as we all know, and
> > maintainers have to deal with code that they don't like every day, so
> > helping them understand tricky corners cannot be bad, IMO.
> >
> >> The old GC won't go away for many years.
> >
> > Maybe not, but then the code in question worked for us for decades, so
> > a probability of a serious error there is quite low, to say the least.
>
> What you are doing is not fixing obvious maintainability bugs which
> might also show up as real bugs in production. You are writing comments
> instead. In another branch. And from what I read so far, I get the
> impression that you are objecting to others making the fixes, in that
> branch.
Yes, I object to making changes in working code that look unsafe or
not clean enough, especially in code that we don't understand well and
for which we have no experts on board. Part of my job, as I see it,
is to keep the development version stable enough, so any change that
might risk destabilizing it without any significant benefits gets
minuses from me.
> Not sure what I should think about this.
I hope you will at least give me the benefit of the doubt that I might
be doing this based on hard-learned experience, even if you do not
agree with my conclusions.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 15:10 ` Eli Zaretskii
@ 2025-01-27 15:27 ` Gerd Möllmann
2025-01-27 15:55 ` Eli Zaretskii
2025-01-28 22:24 ` Jeremy Bryant
0 siblings, 2 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 15:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> What you are doing is not fixing obvious maintainability bugs which
>> might also show up as real bugs in production. You are writing comments
>> instead. In another branch. And from what I read so far, I get the
>> impression that you are objecting to others making the fixes, in that
>> branch.
>
> Yes, I object to making changes in working code that look unsafe or
> not clean enough, especially in code that we don't understand well and
> for which we have no experts on board.
This GC issue is well enough understood that one doesn't have to be an
expert to fix it, wherever it is found. It's the simplest of all
possible rules: protect stuff, remove this "cleverness".
> Part of my job, as I see it, is to keep the development version stable
> enough, so any change that might risk destabilizing it without any
> significant benefits gets minuses from me.
I agree with the general direction, but I disagree completely in this
case. And what is worse, Pip is meanwhile pissed off. I'm no longer
reading the mailing lists. Helmut and others can speak for themselves.
Excellent.
Want to know what I think when igc will land: never. It should be given
up as not realizable due to human factors.
>> Not sure what I should think about this.
>
> I hope you will at least give me the benefit of the doubt that I might
> be doing this based on hard-learned experience, even if you do not
> agree with my conclusions.
Of course, it's nothing personal.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 15:27 ` Gerd Möllmann
@ 2025-01-27 15:55 ` Eli Zaretskii
2025-01-27 16:16 ` Gerd Möllmann
2025-01-28 22:24 ` Jeremy Bryant
1 sibling, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 15:55 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 16:27:19 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> What you are doing is not fixing obvious maintainability bugs which
> >> might also show up as real bugs in production. You are writing comments
> >> instead. In another branch. And from what I read so far, I get the
> >> impression that you are objecting to others making the fixes, in that
> >> branch.
> >
> > Yes, I object to making changes in working code that look unsafe or
> > not clean enough, especially in code that we don't understand well and
> > for which we have no experts on board.
>
> This GC issue is well enough understood that one doesn't have to be an
> expert to fix it, wherever it is found. It's the simplest of all
> possible rules: protect stuff, remove this "cleverness".
I didn't mean GC, I meant font.c. The removal of DEFVAR_LISP_NOPRO
required changes there, and I was not comfortable with the changes
proposed to do that.
> > Part of my job, as I see it, is to keep the development version stable
> > enough, so any change that might risk destabilizing it without any
> > significant benefits gets minuses from me.
>
> I agree with the general direction, but I disagree completely in this
> case. And what is worse, Pip is meanwhile pissed off. I'm no longer
> reading the mailing lists. Helmut and others can speak for themselves.
> Excellent.
I'm sorry this happened, but I don't understand why technical
disagreements should have such an effect. I hope all of you will
reconsider.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 15:55 ` Eli Zaretskii
@ 2025-01-27 16:16 ` Gerd Möllmann
2025-01-27 16:35 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 16:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> I'm sorry this happened, but I don't understand why technical
> disagreements should have such an effect. I hope all of you will
> reconsider.
Could it be that there aren't that many wrong-way drivers, but perhaps
just one?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 16:16 ` Gerd Möllmann
@ 2025-01-27 16:35 ` Eli Zaretskii
2025-01-27 17:07 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 16:35 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 17:16:08 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I'm sorry this happened, but I don't understand why technical
> > disagreements should have such an effect. I hope all of you will
> > reconsider.
>
> Could it be that there aren't that many wrong-way drivers, but perhaps
> just one?
It could be, of course. But once you give me the steering wheel, you
cannot ask me to drive in ways I consider incorrect, can you?
(Fortunately, at least some people tell me at times, both on- and
off-list, that they think I'm driving in the right direction. So at
least I'm not alone here, there are a few more wrong-way drivers with
me.)
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 16:35 ` Eli Zaretskii
@ 2025-01-27 17:07 ` Gerd Möllmann
2025-01-27 18:58 ` tomas
0 siblings, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 17:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 27 Jan 2025 17:16:08 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I'm sorry this happened, but I don't understand why technical
>> > disagreements should have such an effect. I hope all of you will
>> > reconsider.
>>
>> Could it be that there aren't that many wrong-way drivers, but perhaps
>> just one?
>
> It could be, of course. But once you give me the steering wheel, you
> cannot ask me to drive in ways I consider incorrect, can you?
Of course I can, I must even.
Stubbornness is not a virtue. If you feel insecure in GC things, how
about delegating that part to other co-maintainers, who I guess are also
at the steering wheel?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 14:00 ` Eli Zaretskii
2025-01-27 14:18 ` Gerd Möllmann
@ 2025-01-27 17:46 ` Stefan Kangas
2025-01-27 19:40 ` Eli Zaretskii
2025-01-27 22:18 ` Pip Cet via Emacs development discussions.
1 sibling, 2 replies; 76+ messages in thread
From: Stefan Kangas @ 2025-01-27 17:46 UTC (permalink / raw)
To: Eli Zaretskii, Gerd Möllmann; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> If someone suggests a simpler, cleaner change, I might reconsider.
We are now in a situation where the feature/igc developers are
protesting vehemently against this, to the extent that there is even
talk of not merging feature/igc at all. This is not a good outcome.
One side in this discussion argue that removing DEFVAR_LISP_NOPRO is
risk-free, or something close to it, and decreases the risk for GC bugs.
The other side argues that any change comes with inherent risk,
especially in a currently poorly understood area like font.c, and that
keeping what we have is low risk.
Since this discussion seems to revolve around managing risk in different
ways, I would suggest the following compromise:
1. We install the attached patch on master _as an experiment_, which
means that we install it with the understanding that we are keeping
the option open to revert it later. We have used this method in the
past to good effect.
2. We agree to re-evaluate the patch before the fist pretest for Emacs
31.1, or even sooner, keeping the option open to revert it if needed.
3. If there is no trouble with the patch, we leave it as is. The
pretest will give us more opportunities to get this change tested in
various configurations.
4. We keep the option open to revert it at any point during the pretest
also, if it turns out to be causing issues.
I hope that this could make everyone happy, and let us get back to our
regularly scheduled hacking.
Can everyone please let me know what they think?
[-- Attachment #2: 0001-Delete-macro-DEFVAR_LISP_NOPRO.patch --]
[-- Type: text/x-patch, Size: 3986 bytes --]
From b8c75a7641a8e0d44649399d646325a93a564a21 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Mon, 27 Jan 2025 17:52:10 +0100
Subject: [PATCH] Delete macro DEFVAR_LISP_NOPRO
* src/lisp.h (DEFVAR_LISP_NOPRO): Delete macro.
* src/font.c (syms_of_font) <font-weight-table, font-slant-table>
<font-width-table>: Don't use above deleted macro.
(font_style_to_value): Revert recent change.
---
src/font.c | 29 +++++------------------------
src/lisp.h | 6 ------
2 files changed, 5 insertions(+), 30 deletions(-)
diff --git a/src/font.c b/src/font.c
index dfe479f9355..e6c41e41258 100644
--- a/src/font.c
+++ b/src/font.c
@@ -418,24 +418,8 @@ font_style_to_value (enum font_property_index prop, Lisp_Object val,
eassert (len < 255);
elt = make_vector (2, make_fixnum (100));
ASET (elt, 1, val);
- Lisp_Object new_table = CALLN (Fvconcat, table, make_vector (1, elt));
- /* Update the corresponding variable with the new value of the
- modified slot of font_style_table. */
- switch (prop)
- {
- case FONT_WEIGHT_INDEX:
- Vfont_weight_table = new_table;
- break;
- case FONT_SLANT_INDEX:
- Vfont_slant_table = new_table;
- break;
- case FONT_WIDTH_INDEX:
- Vfont_width_table = new_table;
- break;
- default:
- break;
- }
- ASET (font_style_table, prop - FONT_WEIGHT_INDEX, new_table);
+ ASET (font_style_table, prop - FONT_WEIGHT_INDEX,
+ CALLN (Fvconcat, table, make_vector (1, elt)));
return (100 << 8) | (i << 4);
}
else
@@ -5970,7 +5954,7 @@ syms_of_font (void)
table used by the font display code. So we make them read-only,
to avoid this confusing situation. */
- DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
+ DEFVAR_LISP ("font-weight-table", Vfont_weight_table,
doc: /* Vector of valid font weight values.
Each element has the form:
[NUMERIC-VALUE SYMBOLIC-NAME ALIAS-NAME ...]
@@ -5979,23 +5963,20 @@ syms_of_font (void)
Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
make_symbol_constant (intern_c_string ("font-weight-table"));
- DEFVAR_LISP_NOPRO ("font-slant-table", Vfont_slant_table,
+ DEFVAR_LISP ("font-slant-table", Vfont_slant_table,
doc: /* Vector of font slant symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_slant_table = BUILD_STYLE_TABLE (slant_table);
make_symbol_constant (intern_c_string ("font-slant-table"));
- DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table,
+ DEFVAR_LISP ("font-width-table", Vfont_width_table,
doc: /* Alist of font width symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_width_table = BUILD_STYLE_TABLE (width_table);
make_symbol_constant (intern_c_string ("font-width-table"));
- /* Because the above 3 variables are slots in the vector we create
- below, and because that vector is staticpro'd, we don't explicitly
- staticpro the variables, to avoid wasting slots in staticvec[]. */
staticpro (&font_style_table);
font_style_table = CALLN (Fvector, Vfont_weight_table, Vfont_slant_table,
Vfont_width_table);
diff --git a/src/lisp.h b/src/lisp.h
index 2faad895133..fb1ed8c8fa7 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3550,12 +3550,6 @@ #define DEFVAR_LISP(lname, vname, doc) \
= {Lisp_Fwd_Obj, &globals.f_##vname}; \
defvar_lisp (&o_fwd, lname); \
} while (false)
-#define DEFVAR_LISP_NOPRO(lname, vname, doc) \
- do { \
- static struct Lisp_Objfwd const o_fwd \
- = {Lisp_Fwd_Obj, &globals.f_##vname}; \
- defvar_lisp_nopro (&o_fwd, lname); \
- } while (false)
#define DEFVAR_BOOL(lname, vname, doc) \
do { \
static struct Lisp_Boolfwd const b_fwd \
--
2.48.1
^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 17:07 ` Gerd Möllmann
@ 2025-01-27 18:58 ` tomas
2025-01-27 19:22 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: tomas @ 2025-01-27 18:58 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Mon, Jan 27, 2025 at 06:07:53PM +0100, Gerd Möllmann wrote:
[...]
> Stubbornness is not a virtue. If you feel insecure in GC things, how
> about delegating that part to other co-maintainers, who I guess are also
> at the steering wheel?
Sorry, Gerd. For me, this just jumps the shark.
Cheers
--
t
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 18:58 ` tomas
@ 2025-01-27 19:22 ` Gerd Möllmann
2025-01-27 19:51 ` Eli Zaretskii
2025-01-28 5:13 ` tomas
0 siblings, 2 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 19:22 UTC (permalink / raw)
To: tomas; +Cc: Eli Zaretskii, emacs-devel
<tomas@tuxteam.de> writes:
> On Mon, Jan 27, 2025 at 06:07:53PM +0100, Gerd Möllmann wrote:
>
> [...]
>
>> Stubbornness is not a virtue. If you feel insecure in GC things, how
>> about delegating that part to other co-maintainers, who I guess are also
>> at the steering wheel?
>
> Sorry, Gerd. For me, this just jumps the shark.
>
> Cheers
You can't have followed the discussions and not get the impression that
Eli isn't exactly an expert in GC things. And that is relevant, not
absurd.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 17:46 ` Stefan Kangas
@ 2025-01-27 19:40 ` Eli Zaretskii
2025-01-27 22:18 ` Pip Cet via Emacs development discussions.
1 sibling, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 19:40 UTC (permalink / raw)
To: Stefan Kangas; +Cc: gerd.moellmann, emacs-devel
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 27 Jan 2025 11:46:47 -0600
> Cc: emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > If someone suggests a simpler, cleaner change, I might reconsider.
>
> We are now in a situation where the feature/igc developers are
> protesting vehemently against this, to the extent that there is even
> talk of not merging feature/igc at all. This is not a good outcome.
>
> One side in this discussion argue that removing DEFVAR_LISP_NOPRO is
> risk-free, or something close to it, and decreases the risk for GC bugs.
>
> The other side argues that any change comes with inherent risk,
> especially in a currently poorly understood area like font.c, and that
> keeping what we have is low risk.
>
> Since this discussion seems to revolve around managing risk in different
> ways, I would suggest the following compromise:
>
> 1. We install the attached patch on master _as an experiment_, which
> means that we install it with the understanding that we are keeping
> the option open to revert it later. We have used this method in the
> past to good effect.
This patch reverts a fix for a real and unrelated bug: changing the
font style table is not reflected to the relevant Lisp variables,
which confusingly keep the old outdated values. So the patch as you
show it is wrong, IMO. It certainly isn't simpler and cleaner than
what was proposed earlier.
If you insist on removing the macro in the non-MPS build, let's please
do that on the igc branch, but without reverting the bugfix I mention
above. That bugfix is unrelated to the removal of the macro. The
change will then land when we merge the branch.
> 2. We agree to re-evaluate the patch before the fist pretest for Emacs
> 31.1, or even sooner, keeping the option open to revert it if needed.
>
> 3. If there is no trouble with the patch, we leave it as is. The
> pretest will give us more opportunities to get this change tested in
> various configurations.
>
> 4. We keep the option open to revert it at any point during the pretest
> also, if it turns out to be causing issues.
Unfortunately, this practice doesn't work with the code in question.
The experience with font.c and fontset.c code is that changes there
which cause trouble are discovered many moons after they were made.
So let's not rely on this technique because it will not work. If you
insist on changing that against my objections, I agree, under protest,
to making the change now on the branch.
(I still think that this is quite a mountain out of a molehill.)
> I hope that this could make everyone happy, and let us get back to our
> regularly scheduled hacking.
Since you asked: this kind of unfriendly pressure cannot possibly
leave me happy. But I don't want to keep this going any longer,
either.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 19:22 ` Gerd Möllmann
@ 2025-01-27 19:51 ` Eli Zaretskii
2025-01-27 19:57 ` Gerd Möllmann
2025-01-28 5:13 ` tomas
1 sibling, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 19:51 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: tomas, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 20:22:23 +0100
>
> <tomas@tuxteam.de> writes:
>
> > On Mon, Jan 27, 2025 at 06:07:53PM +0100, Gerd Möllmann wrote:
> >
> > [...]
> >
> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
> >> about delegating that part to other co-maintainers, who I guess are also
> >> at the steering wheel?
> >
> > Sorry, Gerd. For me, this just jumps the shark.
> >
> > Cheers
>
> You can't have followed the discussions and not get the impression that
> Eli isn't exactly an expert in GC things. And that is relevant, not
> absurd.
Once again: my objections were not because of the effects on the GC
code.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 19:51 ` Eli Zaretskii
@ 2025-01-27 19:57 ` Gerd Möllmann
2025-01-27 20:00 ` Eli Zaretskii
2025-01-28 5:15 ` tomas
0 siblings, 2 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 19:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: tomas, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>>> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
>> >> about delegating that part to other co-maintainers, who I guess are also
>> >> at the steering wheel?
>> >
>> > Sorry, Gerd. For me, this just jumps the shark.
>> >
>> > Cheers
>>
>> You can't have followed the discussions and not get the impression that
>> Eli isn't exactly an expert in GC things. And that is relevant, not
>> absurd.
>
> Once again: my objections were not because of the effects on the GC
> code.
This is not about a specific patch or something.
Tomas was basically saying my thought of delegating GC stuff to another
maintainer was ridiculous.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 19:57 ` Gerd Möllmann
@ 2025-01-27 20:00 ` Eli Zaretskii
2025-01-27 20:04 ` Gerd Möllmann
2025-01-28 5:15 ` tomas
1 sibling, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 20:00 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: tomas, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 20:57:12 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>>> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
> >> >> about delegating that part to other co-maintainers, who I guess are also
> >> >> at the steering wheel?
> >> >
> >> > Sorry, Gerd. For me, this just jumps the shark.
> >> >
> >> > Cheers
> >>
> >> You can't have followed the discussions and not get the impression that
> >> Eli isn't exactly an expert in GC things. And that is relevant, not
> >> absurd.
> >
> > Once again: my objections were not because of the effects on the GC
> > code.
>
> This is not about a specific patch or something.
>
> Tomas was basically saying my thought of delegating GC stuff to another
> maintainer was ridiculous.
I didn't respond to what Tomas was saying, I responded to what you
were saying about my being non-expert on this and that.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 20:00 ` Eli Zaretskii
@ 2025-01-27 20:04 ` Gerd Möllmann
2025-01-27 20:17 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 20:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: tomas, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
>> Date: Mon, 27 Jan 2025 20:57:12 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>>> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
>> >> >> about delegating that part to other co-maintainers, who I guess are also
>> >> >> at the steering wheel?
>> >> >
>> >> > Sorry, Gerd. For me, this just jumps the shark.
>> >> >
>> >> > Cheers
>> >>
>> >> You can't have followed the discussions and not get the impression that
>> >> Eli isn't exactly an expert in GC things. And that is relevant, not
>> >> absurd.
>> >
>> > Once again: my objections were not because of the effects on the GC
>> > code.
>>
>> This is not about a specific patch or something.
>>
>> Tomas was basically saying my thought of delegating GC stuff to another
>> maintainer was ridiculous.
>
> I didn't respond to what Tomas was saying, I responded to what you
> were saying about my being non-expert on this and that.
And? Does it make my statement that you are not an expert on GC untrue?
And would that fact not be relevant for deciding to delegate or not?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 20:04 ` Gerd Möllmann
@ 2025-01-27 20:17 ` Eli Zaretskii
2025-01-27 20:29 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-27 20:17 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: tomas, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Mon, 27 Jan 2025 21:04:31 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> >> Date: Mon, 27 Jan 2025 20:57:12 +0100
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>>> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
> >> >> >> about delegating that part to other co-maintainers, who I guess are also
> >> >> >> at the steering wheel?
> >> >> >
> >> >> > Sorry, Gerd. For me, this just jumps the shark.
> >> >> >
> >> >> > Cheers
> >> >>
> >> >> You can't have followed the discussions and not get the impression that
> >> >> Eli isn't exactly an expert in GC things. And that is relevant, not
> >> >> absurd.
> >> >
> >> > Once again: my objections were not because of the effects on the GC
> >> > code.
> >>
> >> This is not about a specific patch or something.
> >>
> >> Tomas was basically saying my thought of delegating GC stuff to another
> >> maintainer was ridiculous.
> >
> > I didn't respond to what Tomas was saying, I responded to what you
> > were saying about my being non-expert on this and that.
>
> And? Does it make my statement that you are not an expert on GC untrue?
It's simply irrelevant.
> And would that fact not be relevant for deciding to delegate or not?
No.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 20:17 ` Eli Zaretskii
@ 2025-01-27 20:29 ` Gerd Möllmann
0 siblings, 0 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-27 20:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: tomas, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> And? Does it make my statement that you are not an expert on GC untrue?
>
> It's simply irrelevant.
>
>> And would that fact not be relevant for deciding to delegate or not?
>
> No.
Then good luck with that!
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 17:46 ` Stefan Kangas
2025-01-27 19:40 ` Eli Zaretskii
@ 2025-01-27 22:18 ` Pip Cet via Emacs development discussions.
2025-01-28 12:27 ` Eli Zaretskii
1 sibling, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-01-27 22:18 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, Gerd Möllmann, emacs-devel
"Stefan Kangas" <stefankangas@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> If someone suggests a simpler, cleaner change, I might reconsider.
>
> We are now in a situation where the feature/igc developers are
> protesting vehemently against this, to the extent that there is even
> talk of not merging feature/igc at all. This is not a good outcome.
>
> One side in this discussion argue that removing DEFVAR_LISP_NOPRO is
> risk-free, or something close to it, and decreases the risk for GC bugs.
>
> The other side argues that any change comes with inherent risk,
> especially in a currently poorly understood area like font.c, and that
> keeping what we have is low risk.
>
> Since this discussion seems to revolve around managing risk in different
> ways, I would suggest the following compromise:
>
> 1. We install the attached patch on master _as an experiment_, which
> means that we install it with the understanding that we are keeping
> the option open to revert it later. We have used this method in the
> past to good effect.
>
> 2. We agree to re-evaluate the patch before the fist pretest for Emacs
> 31.1, or even sooner, keeping the option open to revert it if needed.
>
> 3. If there is no trouble with the patch, we leave it as is. The
> pretest will give us more opportunities to get this change tested in
> various configurations.
>
> 4. We keep the option open to revert it at any point during the pretest
> also, if it turns out to be causing issues.
>
> I hope that this could make everyone happy, and let us get back to our
> regularly scheduled hacking.
>
> Can everyone please let me know what they think?
About the patch:
I proposed these two patches as a minimal fix:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
The main difference in your patch is that defvar_lisp_nopro is kept and
remains exported, making your patch even more minimal. This would make
it easier to restore the old behavior if "git revert" fails due to some
unrelated change, so I agree with this change.
The other difference is what's in the .c file comments in lread.c and
alloc.c. The minor issue of preexisting outdated comments should not
stop us here.
As for the compromise proposal:
I've read this as a memorandum of understanding, not a binding contract
or a promise. If that is correct, it sounds good to me.
IIUC, the compromise is meant to apply to this one specific problem
only. This would be a good thing. Let me know if I'm not UC.
This response is about the compromise proposal only.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 19:22 ` Gerd Möllmann
2025-01-27 19:51 ` Eli Zaretskii
@ 2025-01-28 5:13 ` tomas
2025-01-28 12:46 ` Eli Zaretskii
1 sibling, 1 reply; 76+ messages in thread
From: tomas @ 2025-01-28 5:13 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Mon, Jan 27, 2025 at 08:22:23PM +0100, Gerd Möllmann wrote:
> <tomas@tuxteam.de> writes:
>
> > On Mon, Jan 27, 2025 at 06:07:53PM +0100, Gerd Möllmann wrote:
> >
> > [...]
> >
> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
> >> about delegating that part to other co-maintainers, who I guess are also
> >> at the steering wheel?
> >
> > Sorry, Gerd. For me, this just jumps the shark.
> >
> > Cheers
>
> You can't have followed the discussions and not get the impression that
> Eli isn't exactly an expert in GC things. And that is relevant, not
> absurd.
My remark was about style, not GC. And actually having followed the
discussion, I won't discuss GC things with you.
Eli's the maintainer, and, while I won't agree with every decision he
takes, he's doing a pretty good job of it, IMO.
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 19:57 ` Gerd Möllmann
2025-01-27 20:00 ` Eli Zaretskii
@ 2025-01-28 5:15 ` tomas
2025-01-28 5:55 ` Gerd Möllmann
1 sibling, 1 reply; 76+ messages in thread
From: tomas @ 2025-01-28 5:15 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Mon, Jan 27, 2025 at 08:57:12PM +0100, Gerd Möllmann wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>>> >> Stubbornness is not a virtue. If you feel insecure in GC things, how
> >> >> about delegating that part to other co-maintainers, who I guess are also
> >> >> at the steering wheel?
> >> >
> >> > Sorry, Gerd. For me, this just jumps the shark.
> >> >
> >> > Cheers
> >>
> >> You can't have followed the discussions and not get the impression that
> >> Eli isn't exactly an expert in GC things. And that is relevant, not
> >> absurd.
> >
> > Once again: my objections were not because of the effects on the GC
> > code.
>
> This is not about a specific patch or something.
>
> Tomas was basically saying my thought of delegating GC stuff to another
> maintainer was ridiculous.
No: your interpretation is wrong. What I was saying is that your
behaviour of taking your ball and walk away if your don't get your
way is not constructive.
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 5:15 ` tomas
@ 2025-01-28 5:55 ` Gerd Möllmann
2025-01-28 7:26 ` tomas
0 siblings, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-28 5:55 UTC (permalink / raw)
To: tomas; +Cc: Eli Zaretskii, emacs-devel
tomas@tuxteam.de writes:
>> Tomas was basically saying my thought of delegating GC stuff to another
>> maintainer was ridiculous.
>
> No: your interpretation is wrong. What I was saying is that your
> behaviour of taking your ball and walk away if your don't get your
> way is not constructive.
I'm not taking my ball and leaving. I made GNU its own ball, as a copy
of my ball, and others later helped make both balls prettier. GNU still
has its ball. And I said right from the start that I won't maintain
GNU's ball, ever. So much to having to be "constructive".
Shall GNU do with its ball what it wants. I've shared what I have, the
rest is in the end not my beer, but I can speak up when things go down,
and they do.
BTW, just to get everything in one reply, I won't discuss style issues
with you. That's not _your_ beer.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 5:55 ` Gerd Möllmann
@ 2025-01-28 7:26 ` tomas
0 siblings, 0 replies; 76+ messages in thread
From: tomas @ 2025-01-28 7:26 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Tue, Jan 28, 2025 at 06:55:55AM +0100, Gerd Möllmann wrote:
> tomas@tuxteam.de writes:
>
> >> Tomas was basically saying my thought of delegating GC stuff to another
> >> maintainer was ridiculous.
> >
> > No: your interpretation is wrong. What I was saying is that your
> > behaviour of taking your ball and walk away if your don't get your
> > way is not constructive.
>
> I'm not taking my ball and leaving. I made GNU its own ball, as a copy
> of my ball, and others later helped make both balls prettier. GNU still
> has its ball. And I said right from the start that I won't maintain
> GNU's ball, ever. So much to having to be "constructive".
>
> Shall GNU do with its ball what it wants. I've shared what I have, the
> rest is in the end not my beer, but I can speak up when things go down,
> and they do.
>
> BTW, just to get everything in one reply, I won't discuss style issues
> with you. That's not _your_ beer.
We seem to agree. Let's leave things at that.
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 22:18 ` Pip Cet via Emacs development discussions.
@ 2025-01-28 12:27 ` Eli Zaretskii
2025-01-28 20:06 ` Pip Cet via Emacs development discussions.
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-28 12:27 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Mon, 27 Jan 2025 22:18:22 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, emacs-devel@gnu.org
>
> About the patch:
>
> I proposed these two patches as a minimal fix:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
Yes, I think we should use those two, thanks.
> IIUC, the compromise is meant to apply to this one specific problem
> only.
Yes, that's the intent. But if we install this on the igc branch,
there's no need to do anything in steps 2 to 4, as the change will
wind up on master when we merge the branch.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 5:13 ` tomas
@ 2025-01-28 12:46 ` Eli Zaretskii
2025-01-28 12:50 ` tomas
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-28 12:46 UTC (permalink / raw)
To: tomas; +Cc: gerd.moellmann, emacs-devel
> Date: Tue, 28 Jan 2025 06:13:19 +0100
> From: tomas@tuxteam.de
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>
> Eli's the maintainer, and, while I won't agree with every decision he
> takes, he's doing a pretty good job of it, IMO.
To be fair, there are 3 of us co-maintainers. So I will take one
third of that, thank you ;-)
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 12:46 ` Eli Zaretskii
@ 2025-01-28 12:50 ` tomas
0 siblings, 0 replies; 76+ messages in thread
From: tomas @ 2025-01-28 12:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
On Tue, Jan 28, 2025 at 02:46:24PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 28 Jan 2025 06:13:19 +0100
> > From: tomas@tuxteam.de
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >
> > Eli's the maintainer, and, while I won't agree with every decision he
> > takes, he's doing a pretty good job of it, IMO.
>
> To be fair, there are 3 of us co-maintainers. So I will take one
> third of that, thank you ;-)
I'd give each one three-thirds, if it was me :)
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 12:27 ` Eli Zaretskii
@ 2025-01-28 20:06 ` Pip Cet via Emacs development discussions.
2025-01-28 21:31 ` Stefan Kangas
0 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-01-28 20:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Mon, 27 Jan 2025 22:18:22 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, emacs-devel@gnu.org
>>
>> About the patch:
>>
>> I proposed these two patches as a minimal fix:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
>
> Yes, I think we should use those two, thanks.
Great, hoping it'll happen soon then. I hope Stefan Kangas and Gerd
agree. (But see below about the "which branch" question).
>> IIUC, the compromise is meant to apply to this one specific problem
>> only.
>
> Yes, that's the intent.
Good. If a situation like this happens again, hopefully we will have an
example of how it worked in this case, and can improve it or do
something totally different.
> But if we install this on the igc branch, there's no need to do
> anything in steps 2 to 4, as the change will wind up on master when we
> merge the branch.
I'm not sure which patch you're planning to install on feature/igc;
maybe you should just push what you think would be the best equivalent
of Stefan's suggestion here.
Worst case, reverting two commits isn't much harder than reverting just
one (my personal workflow often involves long commit stretches by that
Pip guy who doesn't know what he's doing).
> I hope that this could make everyone happy, and let us get back to our
> regularly scheduled hacking.
From my POV, that would be great.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 20:06 ` Pip Cet via Emacs development discussions.
@ 2025-01-28 21:31 ` Stefan Kangas
2025-01-29 9:46 ` Pip Cet via Emacs development discussions.
0 siblings, 1 reply; 76+ messages in thread
From: Stefan Kangas @ 2025-01-28 21:31 UTC (permalink / raw)
To: Pip Cet, Eli Zaretskii; +Cc: gerd.moellmann, emacs-devel
Pip Cet <pipcet@protonmail.com> writes:
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
>>> Date: Mon, 27 Jan 2025 22:18:22 +0000
>>> From: Pip Cet <pipcet@protonmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, emacs-devel@gnu.org
>>>
>>> I proposed these two patches as a minimal fix:
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
>>
>> Yes, I think we should use those two, thanks.
>
> Great, hoping it'll happen soon then. I hope Stefan Kangas and Gerd
> agree. (But see below about the "which branch" question).
...
> I'm not sure which patch you're planning to install on feature/igc;
> maybe you should just push what you think would be the best equivalent
> of Stefan's suggestion here.
Pip, could you please install the above two mentioned patches on
feature/igc?
Thanks in advance.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 15:27 ` Gerd Möllmann
2025-01-27 15:55 ` Eli Zaretskii
@ 2025-01-28 22:24 ` Jeremy Bryant
2025-01-29 4:44 ` Gerd Möllmann
1 sibling, 1 reply; 76+ messages in thread
From: Jeremy Bryant @ 2025-01-28 22:24 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> What you are doing is not fixing obvious maintainability bugs which
>>> might also show up as real bugs in production. You are writing comments
>>> instead. In another branch. And from what I read so far, I get the
>>> impression that you are objecting to others making the fixes, in that
>>> branch.
>>
>> Yes, I object to making changes in working code that look unsafe or
>> not clean enough, especially in code that we don't understand well and
>> for which we have no experts on board.
>
> This GC issue is well enough understood that one doesn't have to be an
> expert to fix it, wherever it is found. It's the simplest of all
> possible rules: protect stuff, remove this "cleverness".
Hi Gerd,
Forgive me if this is an oversimplified summary, but it appears you have
been working on a highly technical branch, with potentially great
benefits for Emacs, with lots of technical subtleties, and care a lot about Emacs.
I am a non-expert in GC.
As such would you have any guidance on how to
understand the benefits of the igc branch and the 'easiest' entry points
into the code for study purposes?
thanks in advance for any pointers
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 22:24 ` Jeremy Bryant
@ 2025-01-29 4:44 ` Gerd Möllmann
2025-01-29 23:09 ` Jeremy Bryant
0 siblings, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-29 4:44 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Eli Zaretskii, emacs-devel
Jeremy Bryant <jb@jeremybryant.net> writes:
> and care a lot about Emacs.
To _very_ varying degrees over the decades, including two with zero
interest. It's a long story :-).
>
> I am a non-expert in GC.
> As such would you have any guidance on how to
> understand the benefits of the igc branch
I recommend starting with admin/igc.org. I'm not a particularly good
explaining things, but I'd hope it's helpful anyway.
> and the 'easiest' entry points into the code for study purposes?
MPS is a library, so one has to understand its API first; igc.org has
links to the MPS documentation. The documentation includes a Guide that
I would start with.
Once you've done that, read the rest of igc.org, and then see how igc.c
uses the API. I'd start here
igc.c:
5235 void
5236 init_igc (void)
5237 {
5238 /* Returns previous handler. */
5239 (void) mps_lib_assert_fail_install (igc_assert_fail);
5240 global_igc = make_igc ();
5241 add_main_thread ();
5242 set_state (IGC_STATE_USABLE_PARKED);
5243 }
This is called very early when Emacs starts. It sets up everything so
that the GC is usable. Follow the call tree and look up MPS API
functions being called in the MPS Reference.
Then ask questions :-).
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-28 21:31 ` Stefan Kangas
@ 2025-01-29 9:46 ` Pip Cet via Emacs development discussions.
2025-01-29 13:44 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-01-29 9:46 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, gerd.moellmann, emacs-devel
"Stefan Kangas" <stefankangas@gmail.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>>>> Date: Mon, 27 Jan 2025 22:18:22 +0000
>>>> From: Pip Cet <pipcet@protonmail.com>
>>>> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, emacs-devel@gnu.org
>>>>
>>>> I proposed these two patches as a minimal fix:
>>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
>>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
>>>
>>> Yes, I think we should use those two, thanks.
>>
>> Great, hoping it'll happen soon then. I hope Stefan Kangas and Gerd
>> agree. (But see below about the "which branch" question).
> ...
>> I'm not sure which patch you're planning to install on feature/igc;
>> maybe you should just push what you think would be the best equivalent
>> of Stefan's suggestion here.
>
> Pip, could you please install the above two mentioned patches on
> feature/igc?
Unfortunately, there are merge conflicts. I resolved those, and here's
the patch I was going to apply until I reread
https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg01065.html
More below.
From f177decb503698304bd2f1a31c33118cd4121f21 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@protonmail.com>
Subject: [PATCH] Remove DEFVAR_LISP_NOPRO (bug#75521)
* src/alloc.c (process_mark_stack): Adjust comment.
* src/font.c (syms_of_font): Use 'DEFVAR_LISP_NOPRO', not
'DEFVAR_LISP'. Adjust comment.
(font_style_to_value): Restore previous behavior of letting
user-visible and internal font style tables diverge.
* src/lisp.h (DEFVAR_LISP_NOPRO): Macro removed.
* src/lread.c (defvar_lisp_nopro): Function removed.
(defvar_lisp): Inline defvar_lisp_nopro here.
---
src/alloc.c | 4 +---
src/font.c | 29 +++++------------------------
src/lisp.h | 21 +--------------------
src/lread.c | 14 ++------------
4 files changed, 9 insertions(+), 59 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index 9437bedf650..2f962d4d861 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7632,9 +7632,7 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0)
/* If the value is forwarded to a buffer or keyboard field,
these are marked when we see the corresponding object.
And if it's forwarded to a C variable, either it's not
- a Lisp_Object var, or it's staticpro'd already, or it's
- reachable from font_style_table which is also
- staticpro'd. */
+ a Lisp_Object var or it's staticpro'd already. */
break;
default: emacs_abort ();
}
diff --git a/src/font.c b/src/font.c
index dfe479f9355..e6c41e41258 100644
--- a/src/font.c
+++ b/src/font.c
@@ -418,24 +418,8 @@ font_style_to_value (enum font_property_index prop, Lisp_Object val,
eassert (len < 255);
elt = make_vector (2, make_fixnum (100));
ASET (elt, 1, val);
- Lisp_Object new_table = CALLN (Fvconcat, table, make_vector (1, elt));
- /* Update the corresponding variable with the new value of the
- modified slot of font_style_table. */
- switch (prop)
- {
- case FONT_WEIGHT_INDEX:
- Vfont_weight_table = new_table;
- break;
- case FONT_SLANT_INDEX:
- Vfont_slant_table = new_table;
- break;
- case FONT_WIDTH_INDEX:
- Vfont_width_table = new_table;
- break;
- default:
- break;
- }
- ASET (font_style_table, prop - FONT_WEIGHT_INDEX, new_table);
+ ASET (font_style_table, prop - FONT_WEIGHT_INDEX,
+ CALLN (Fvconcat, table, make_vector (1, elt)));
return (100 << 8) | (i << 4);
}
else
@@ -5970,7 +5954,7 @@ syms_of_font (void)
table used by the font display code. So we make them read-only,
to avoid this confusing situation. */
- DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
+ DEFVAR_LISP ("font-weight-table", Vfont_weight_table,
doc: /* Vector of valid font weight values.
Each element has the form:
[NUMERIC-VALUE SYMBOLIC-NAME ALIAS-NAME ...]
@@ -5979,23 +5963,20 @@ syms_of_font (void)
Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
make_symbol_constant (intern_c_string ("font-weight-table"));
- DEFVAR_LISP_NOPRO ("font-slant-table", Vfont_slant_table,
+ DEFVAR_LISP ("font-slant-table", Vfont_slant_table,
doc: /* Vector of font slant symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_slant_table = BUILD_STYLE_TABLE (slant_table);
make_symbol_constant (intern_c_string ("font-slant-table"));
- DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table,
+ DEFVAR_LISP ("font-width-table", Vfont_width_table,
doc: /* Alist of font width symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_width_table = BUILD_STYLE_TABLE (width_table);
make_symbol_constant (intern_c_string ("font-width-table"));
- /* Because the above 3 variables are slots in the vector we create
- below, and because that vector is staticpro'd, we don't explicitly
- staticpro the variables, to avoid wasting slots in staticvec[]. */
staticpro (&font_style_table);
font_style_table = CALLN (Fvector, Vfont_weight_table, Vfont_slant_table,
Vfont_width_table);
diff --git a/src/lisp.h b/src/lisp.h
index 98c56e8ea1e..71b07f8dbc8 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3780,7 +3780,6 @@ call0 (Lisp_Object fn)
}
extern void defvar_lisp (struct Lisp_Fwd const *, char const *);
-extern void defvar_lisp_nopro (struct Lisp_Fwd const *, char const *);
extern void defvar_bool (struct Lisp_Fwd const *, char const *);
extern void defvar_int (struct Lisp_Fwd const *, char const *);
extern void defvar_kboard (struct Lisp_Fwd const *, char const *);
@@ -3800,31 +3799,13 @@ call0 (Lisp_Object fn)
#define cons_cells_consed globals.f_cons_cells_consed
All C code uses the `cons_cells_consed' name. This is all done
- this way to support indirection for multi-threaded Emacs.
-
- DEFVAR_LISP staticpro's the variable; DEFVAR_LISP_NOPRO does not, and
- is used for variables that are protected in other ways (e.g., because
- they can be accessed from another variable, which is itself
- protected, see font_style_table on font.c as an example). This is
- not used in the HAVE_MPS build, where DEFVAR_LISP_NOPRO is equivalent
- to DEFVAR_LISP. */
-
+ this way to support indirection for multi-threaded Emacs. */
#define DEFVAR_LISP(lname, vname, doc) \
do { \
static struct Lisp_Fwd const o_fwd \
= {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \
defvar_lisp (&o_fwd, lname); \
} while (false)
-#ifdef HAVE_MPS
-#define DEFVAR_LISP_NOPRO DEFVAR_LISP
-#else
-#define DEFVAR_LISP_NOPRO(lname, vname, doc) \
- do { \
- static struct Lisp_Fwd const o_fwd \
- = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \
- defvar_lisp_nopro (&o_fwd, lname); \
- } while (false)
-#endif
#define DEFVAR_BOOL(lname, vname, doc) \
do { \
static struct Lisp_Fwd const b_fwd \
diff --git a/src/lread.c b/src/lread.c
index 95ef9fbb628..e42e3f51b23 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -5492,25 +5492,15 @@ defvar_bool (struct Lisp_Fwd const *b_fwd, char const *namestring)
}
/* Similar but define a variable whose value is the Lisp Object stored
- at address. Two versions: with and without gc-marking of the C
- variable. The nopro version is used when that variable will be
- gc-marked for some other reason, since marking the same slot twice
- can cause trouble with strings. */
+ at address. */
void
-defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring)
+defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring)
{
eassert (o_fwd->type == Lisp_Fwd_Obj);
Lisp_Object sym = intern_c_string (namestring);
XBARE_SYMBOL (sym)->u.s.declared_special = true;
XBARE_SYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED;
SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd);
-}
-
-void
-defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring)
-{
- eassert (o_fwd->type == Lisp_Fwd_Obj);
- defvar_lisp_nopro (o_fwd, namestring);
staticpro (o_fwd->u.objvar);
}
--
2.47.1
Rereading
https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg01065.html
leaves me with a distinct urge to respond to it in detail, so I decided
not to, for now, since those urges don't usually go anywhere.
So my reaction is simply to be left wondering what, if anything, Eli
wants to agree to.
Eli, is it okay to apply this patch? I'm ignoring the master branch for
now, this is only about feature/igc. A normal merge process for
feature/igc, if it ever happens, would then make
8d471adecef540d49807dad114f7a11fb3fe2a95 go away on the master branch.
Pip
^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 9:46 ` Pip Cet via Emacs development discussions.
@ 2025-01-29 13:44 ` Eli Zaretskii
2025-01-29 17:51 ` Pip Cet via Emacs development discussions.
2025-01-30 10:41 ` Pip Cet via Emacs development discussions.
0 siblings, 2 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-29 13:44 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Wed, 29 Jan 2025 09:46:24 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> "Stefan Kangas" <stefankangas@gmail.com> writes:
>
> > Pip Cet <pipcet@protonmail.com> writes:
> >
> >> "Eli Zaretskii" <eliz@gnu.org> writes:
> >>
> >>>> Date: Mon, 27 Jan 2025 22:18:22 +0000
> >>>> From: Pip Cet <pipcet@protonmail.com>
> >>>> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, emacs-devel@gnu.org
> >>>>
> >>>> I proposed these two patches as a minimal fix:
> >>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
> >>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
> >>>
> >>> Yes, I think we should use those two, thanks.
> >>
> >> Great, hoping it'll happen soon then. I hope Stefan Kangas and Gerd
> >> agree. (But see below about the "which branch" question).
> > ...
> >> I'm not sure which patch you're planning to install on feature/igc;
> >> maybe you should just push what you think would be the best equivalent
> >> of Stefan's suggestion here.
> >
> > Pip, could you please install the above two mentioned patches on
> > feature/igc?
>
> Unfortunately, there are merge conflicts. I resolved those, and here's
> the patch I was going to apply until I reread
>
> https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg01065.html
>
> More below.
The patch you proposed, like that of Stefan, reverts the fix for a
separate issue: if font_style_to_value extends the style table, the
Vfont_* variables keep their old values instead of reflecting the
changes to the style table. I don't think this is right, so I'd
prefer to keep that fix, as it doesn't affect, and isn't affected by,
removal of DEFVAR_LISP_NOPRO and defvar_lisp_nopro. Am I missing
something?
> Eli, is it okay to apply this patch? I'm ignoring the master branch for
> now, this is only about feature/igc. A normal merge process for
> feature/igc, if it ever happens, would then make
> 8d471adecef540d49807dad114f7a11fb3fe2a95 go away on the master branch.
I meant to make the change on feature/igc, indeed, and then have it
merged when the branch lands on master.
To avoid asking you and Stefan do something that I can easily do
myself, I made the change I had in mind, see the patch below. It is a
proper subset of the patch you proposed, AFAICT. I didn't yet install
it, because I have a feeling I'm missing something here, since both
you and Stefan wanted to remove the changes in commit 8d471adecef, and
I don't understand why.
If there are no objections to the patch below, I will install it on
feature/igc. If you do have objections, please describe them.
Thanks.
diff --git a/src/font.c b/src/font.c
index dfe479f..5ee3615 100644
--- a/src/font.c
+++ b/src/font.c
@@ -5970,7 +5970,7 @@ syms_of_font (void)
table used by the font display code. So we make them read-only,
to avoid this confusing situation. */
- DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
+ DEFVAR_LISP ("font-weight-table", Vfont_weight_table,
doc: /* Vector of valid font weight values.
Each element has the form:
[NUMERIC-VALUE SYMBOLIC-NAME ALIAS-NAME ...]
@@ -5979,14 +5979,14 @@ syms_of_font (void)
Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
make_symbol_constant (intern_c_string ("font-weight-table"));
- DEFVAR_LISP_NOPRO ("font-slant-table", Vfont_slant_table,
+ DEFVAR_LISP ("font-slant-table", Vfont_slant_table,
doc: /* Vector of font slant symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_slant_table = BUILD_STYLE_TABLE (slant_table);
make_symbol_constant (intern_c_string ("font-slant-table"));
- DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table,
+ DEFVAR_LISP ("font-width-table", Vfont_width_table,
doc: /* Alist of font width symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
diff --git a/src/lisp.h b/src/lisp.h
index 98c56e8..5bb05ed 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3780,7 +3780,6 @@ call0 (Lisp_Object fn)
}
extern void defvar_lisp (struct Lisp_Fwd const *, char const *);
-extern void defvar_lisp_nopro (struct Lisp_Fwd const *, char const *);
extern void defvar_bool (struct Lisp_Fwd const *, char const *);
extern void defvar_int (struct Lisp_Fwd const *, char const *);
extern void defvar_kboard (struct Lisp_Fwd const *, char const *);
@@ -3802,12 +3801,7 @@ call0 (Lisp_Object fn)
All C code uses the `cons_cells_consed' name. This is all done
this way to support indirection for multi-threaded Emacs.
- DEFVAR_LISP staticpro's the variable; DEFVAR_LISP_NOPRO does not, and
- is used for variables that are protected in other ways (e.g., because
- they can be accessed from another variable, which is itself
- protected, see font_style_table on font.c as an example). This is
- not used in the HAVE_MPS build, where DEFVAR_LISP_NOPRO is equivalent
- to DEFVAR_LISP. */
+ DEFVAR_LISP staticpro's the variable. */
#define DEFVAR_LISP(lname, vname, doc) \
do { \
@@ -3815,16 +3809,6 @@ #define DEFVAR_LISP(lname, vname, doc) \
= {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \
defvar_lisp (&o_fwd, lname); \
} while (false)
-#ifdef HAVE_MPS
-#define DEFVAR_LISP_NOPRO DEFVAR_LISP
-#else
-#define DEFVAR_LISP_NOPRO(lname, vname, doc) \
- do { \
- static struct Lisp_Fwd const o_fwd \
- = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \
- defvar_lisp_nopro (&o_fwd, lname); \
- } while (false)
-#endif
#define DEFVAR_BOOL(lname, vname, doc) \
do { \
static struct Lisp_Fwd const b_fwd \
diff --git a/src/lread.c b/src/lread.c
index 95ef9fb..e42e3f5 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -5492,25 +5492,15 @@ defvar_bool (struct Lisp_Fwd const *b_fwd, char const *namestring)
}
/* Similar but define a variable whose value is the Lisp Object stored
- at address. Two versions: with and without gc-marking of the C
- variable. The nopro version is used when that variable will be
- gc-marked for some other reason, since marking the same slot twice
- can cause trouble with strings. */
+ at address. */
void
-defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring)
+defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring)
{
eassert (o_fwd->type == Lisp_Fwd_Obj);
Lisp_Object sym = intern_c_string (namestring);
XBARE_SYMBOL (sym)->u.s.declared_special = true;
XBARE_SYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED;
SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd);
-}
-
-void
-defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring)
-{
- eassert (o_fwd->type == Lisp_Fwd_Obj);
- defvar_lisp_nopro (o_fwd, namestring);
staticpro (o_fwd->u.objvar);
}
^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 13:44 ` Eli Zaretskii
@ 2025-01-29 17:51 ` Pip Cet via Emacs development discussions.
2025-01-29 19:11 ` Eli Zaretskii
2025-01-30 10:41 ` Pip Cet via Emacs development discussions.
1 sibling, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-01-29 17:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
> If there are no objections to the patch below, I will install it on
> feature/igc.
Yes, I have objections.
> If you do have objections, please describe them.
I will, but please give me some time. Assuming, that is, Stefan Kangas
either doesn't do so earlier or that he does and there is still
something left for me to add.
Thanks
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 17:51 ` Pip Cet via Emacs development discussions.
@ 2025-01-29 19:11 ` Eli Zaretskii
0 siblings, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-29 19:11 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Wed, 29 Jan 2025 17:51:57 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
> > If there are no objections to the patch below, I will install it on
> > feature/igc.
>
> Yes, I have objections.
>
> > If you do have objections, please describe them.
>
> I will, but please give me some time.
Sure, take your time.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 4:44 ` Gerd Möllmann
@ 2025-01-29 23:09 ` Jeremy Bryant
2025-01-30 5:11 ` Gerd Möllmann
` (2 more replies)
0 siblings, 3 replies; 76+ messages in thread
From: Jeremy Bryant @ 2025-01-29 23:09 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Jeremy Bryant <jb@jeremybryant.net> writes:
>
>
>> and care a lot about Emacs.
>
> To _very_ varying degrees over the decades, including two with zero
> interest. It's a long story :-).
I hear it's a long story. After first using Emacs in the 90's, I
discontinued for unfathomable reasons. I also therefore missed the
Emacs releases you did as maintainer. I was recently studying the
xdisp.c code, to which M-x vc-annotate tells me you made large
contributions around 1999-2001 at least. I find your code comments
helpful to learn about the code. Thanks for that.
Emacs itself is also a long story. It takes time to work on large
features.
>> I am a non-expert in GC.
>> As such would you have any guidance on how to
>> understand the benefits of the igc branch
>
> I recommend starting with admin/igc.org. I'm not a particularly good
> explaining things, but I'd hope it's helpful anyway.
>
>> and the 'easiest' entry points into the code for study purposes?
>
> MPS is a library, so one has to understand its API first; igc.org has
> links to the MPS documentation. The documentation includes a Guide that
> I would start with.
>
> Once you've done that, read the rest of igc.org, and then see how igc.c
> uses the API. I'd start here
>
> igc.c:
> 5235 void
> 5236 init_igc (void)
> 5237 {
> 5238 /* Returns previous handler. */
> 5239 (void) mps_lib_assert_fail_install (igc_assert_fail);
> 5240 global_igc = make_igc ();
> 5241 add_main_thread ();
> 5242 set_state (IGC_STATE_USABLE_PARKED);
> 5243 }
>
> This is called very early when Emacs starts. It sets up everything so
> that the GC is usable. Follow the call tree and look up MPS API
> functions being called in the MPS Reference.
>
> Then ask questions :-).
Thanks for the detailed description and guide. I will read up and try
to ask questions.
Furthermore this succinct summary and entry point may
help guide others now, on the road to this large feature.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 23:09 ` Jeremy Bryant
@ 2025-01-30 5:11 ` Gerd Möllmann
2025-01-30 7:52 ` Eli Zaretskii
2025-01-31 22:48 ` igc testing and bug reports -was- " Jeremy Bryant
2 siblings, 0 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-01-30 5:11 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Eli Zaretskii, emacs-devel
Jeremy Bryant <jb@jeremybryant.net> writes:
> I was recently studying the xdisp.c code, to which M-x vc-annotate
> tells me you made large contributions around 1999-2001 at least.
(A gripping thriller involving XEmacs, covert development, and a big
bang :-). Not often enough mentioned, Stefan Monnier and Michael Sperber have
written "Evolution of Emacs Lisp". I can only recommend it for people
interested in the history of Emacs.
https://dl.acm.org/doi/pdf/10.1145/3386324 )
> I find your code comments helpful to learn about the code. Thanks for
> that.
Most of that is due to the people, notably Eli, who have worked on it
since I left. Had to be said.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 23:09 ` Jeremy Bryant
2025-01-30 5:11 ` Gerd Möllmann
@ 2025-01-30 7:52 ` Eli Zaretskii
2025-01-31 22:48 ` igc testing and bug reports -was- " Jeremy Bryant
2 siblings, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-30 7:52 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: gerd.moellmann, emacs-devel
> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Wed, 29 Jan 2025 23:09:05 +0000
>
> I hear it's a long story. After first using Emacs in the 90's, I
> discontinued for unfathomable reasons. I also therefore missed the
> Emacs releases you did as maintainer. I was recently studying the
> xdisp.c code, to which M-x vc-annotate tells me you made large
> contributions around 1999-2001 at least. I find your code comments
> helpful to learn about the code. Thanks for that.
Gerd basically rewrote that file. It was around 3500 lines in Emacs
19, which became 10 times that in Emacs 21.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-29 13:44 ` Eli Zaretskii
2025-01-29 17:51 ` Pip Cet via Emacs development discussions.
@ 2025-01-30 10:41 ` Pip Cet via Emacs development discussions.
2025-01-30 10:59 ` Eli Zaretskii
1 sibling, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-01-30 10:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Wed, 29 Jan 2025 09:46:24 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>>
>> "Stefan Kangas" <stefankangas@gmail.com> writes:
>>
>> > Pip Cet <pipcet@protonmail.com> writes:
>> >
>> >> "Eli Zaretskii" <eliz@gnu.org> writes:
>> >>
>> >>>> Date: Mon, 27 Jan 2025 22:18:22 +0000
>> >>>> From: Pip Cet <pipcet@protonmail.com>
>> >>>> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, emacs-devel@gnu.org
>> >>>>
>> >>>> I proposed these two patches as a minimal fix:
>> >>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
>> >>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88
>> >>>
>> >>> Yes, I think we should use those two, thanks.
>> >>
>> >> Great, hoping it'll happen soon then. I hope Stefan Kangas and Gerd
>> >> agree. (But see below about the "which branch" question).
>> > ...
>> >> I'm not sure which patch you're planning to install on feature/igc;
>> >> maybe you should just push what you think would be the best equivalent
>> >> of Stefan's suggestion here.
>> >
>> > Pip, could you please install the above two mentioned patches on
>> > feature/igc?
>>
>> Unfortunately, there are merge conflicts. I resolved those, and here's
>> the patch I was going to apply until I reread
>>
>> https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg01065.html
>>
>> More below.
>
> The patch you proposed, like that of Stefan, reverts the fix for a
It reverts a hastily-conceived behavior change in font.c which may have
reduced some crashes and triggered some others.
As I said:
"Not really a benefit: updating the variables might expose other
(crashable) bugs more."
That was assuming DEFVAR_LISP_NOPRO would stay. If we agree that is to
be removed, the potential problems remain but the benefits disappear.
> separate issue: if font_style_to_value extends the style table, the
^^^^^^^^
If it's a separate issue, we should fix it separately.
> Vfont_* variables keep their old values instead of reflecting the
> changes to the style table.
Indeed. That's surprising, but documented and the established
behavior, and you changed only half of it.
> I don't think this is right,
If you want to change this behavior, the right way is to look at the
second patch I provided, which made that change by removing
Vfont_style_table entirely, fixing both possibilities of disconnecting
the internal from the Lisp-visible tables.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521;msg=37
> so I'd prefer to keep that fix, as it doesn't affect, and isn't
> affected by, removal of DEFVAR_LISP_NOPRO and defvar_lisp_nopro.
The fix is a workaround to avoid crashes caused by DEFVAR_LISP_NOPRO.
Removing DEFVAR_LISP_NOPRO means no "fix" is needed here.
>> Eli, is it okay to apply this patch? I'm ignoring the master branch for
>> now, this is only about feature/igc. A normal merge process for
>> feature/igc, if it ever happens, would then make
>> 8d471adecef540d49807dad114f7a11fb3fe2a95 go away on the master branch.
>
> I meant to make the change on feature/igc, indeed, and then have it
> merged when the branch lands on master.
Considering the "if it ever happens" part, let's find a solution for
feature/igc first. Any merge of these changes will require manual
intervention, given the complex commit history so far, in order to
ensure no problematic comments or behavior changes remain on the merged
master branch.
> To avoid asking you and Stefan do something that I can easily do
> myself, I made the change I had in mind, see the patch below. It is a
> proper subset of the patch you proposed, AFAICT. I didn't yet install
> it, because I have a feeling I'm missing something here, since both
> you and Stefan wanted to remove the changes in commit 8d471adecef, and
> I don't understand why.
>
> If there are no objections to the patch below, I will install it on
> feature/igc. If you do have objections, please describe them.
>
> Thanks.
>
> diff --git a/src/font.c b/src/font.c
> index dfe479f..5ee3615 100644
> --- a/src/font.c
> +++ b/src/font.c
> @@ -5970,7 +5970,7 @@ syms_of_font (void)
> table used by the font display code. So we make them read-only,
> to avoid this confusing situation. */
>
> - DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
> + DEFVAR_LISP ("font-weight-table", Vfont_weight_table,
> doc: /* Vector of valid font weight values.
> Each element has the form:
> [NUMERIC-VALUE SYMBOLIC-NAME ALIAS-NAME ...]
> @@ -5979,14 +5979,14 @@ syms_of_font (void)
> Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
> make_symbol_constant (intern_c_string ("font-weight-table"));
>
> - DEFVAR_LISP_NOPRO ("font-slant-table", Vfont_slant_table,
> + DEFVAR_LISP ("font-slant-table", Vfont_slant_table,
> doc: /* Vector of font slant symbols vs the corresponding numeric values.
> See `font-weight-table' for the format of the vector.
> This variable cannot be set; trying to do so will signal an error. */);
> Vfont_slant_table = BUILD_STYLE_TABLE (slant_table);
> make_symbol_constant (intern_c_string ("font-slant-table"));
>
> - DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table,
> + DEFVAR_LISP ("font-width-table", Vfont_width_table,
> doc: /* Alist of font width symbols vs the corresponding numeric values.
> See `font-weight-table' for the format of the vector.
> This variable cannot be set; trying to do so will signal an error. */);
This part was dropped:
This variable cannot be set; trying to do so will signal an error. */);
Vfont_width_table = BUILD_STYLE_TABLE (width_table);
make_symbol_constant (intern_c_string ("font-width-table"));
- /* Because the above 3 variables are slots in the vector we create
- below, and because that vector is staticpro'd, we don't explicitly
- staticpro the variables, to avoid wasting slots in staticvec[]. */
staticpro (&font_style_table);
font_style_table = CALLN (Fvector, Vfont_weight_table, Vfont_slant_table,
Vfont_width_table);
If that wasn't intentional, please provide a corrected patch, and
indicate what the base version is. Thanks!
The alloc.c part was also dropped.
Sorry this was long and technical.
My impression is Stefan Kangas made a compromise proposal, to fix this
on master; you disagreed.
I suggested thinking about a second compromise proposal (if I implied
this would be sufficient, I misspoke), fixing this on feature/igc and
leaving the obsolete code on master until feature/igc is merged, if that
ever happens; you disagreed.
Your counterproposal is a patch reduced even further, to the point where
it leaves in two of the four comments telling people to avoid staticpro,
which they can no longer do. Here, I have to disagree.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-30 10:41 ` Pip Cet via Emacs development discussions.
@ 2025-01-30 10:59 ` Eli Zaretskii
2025-01-30 11:52 ` Pip Cet via Emacs development discussions.
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-30 10:59 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Thu, 30 Jan 2025 10:41:08 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
> > The patch you proposed, like that of Stefan, reverts the fix for a
>
> It reverts a hastily-conceived behavior change in font.c which may have
> reduced some crashes and triggered some others.
There was no haste. You pointed out a problem, and I agreed that it
was a problem and installed a fix for it.
> As I said:
>
> "Not really a benefit: updating the variables might expose other
> (crashable) bugs more."
If you can point them out now, please do. Otherwise, let's wait for
them to be reported, and let's fix them at that time. This code is
very old and stable, so I have no reasons to consider it having bugs
unless they are reported with all the relevant details.
> That was assuming DEFVAR_LISP_NOPRO would stay. If we agree that is to
> be removed, the potential problems remain but the benefits disappear.
The benefit is to remove the problematic and confusing behavior
whereby the code intended to change the style tables, but the
variables exposing the styles to Lisp are not updated. This benefit
remains. And it has nothing to do with removing DEFVAR_LISP_NOPRO.
> > separate issue: if font_style_to_value extends the style table, the
> ^^^^^^^^
>
> If it's a separate issue, we should fix it separately.
I did fix it separately. The commit which fixed that didn't touch
DEFVAR_LISP_NOPRO or defvar_lisp_nopro.
> > Vfont_* variables keep their old values instead of reflecting the
> > changes to the style table.
>
> Indeed. That's surprising, but documented and the established
> behavior, and you changed only half of it.
It's neither documented nor established, AFAICT. What _is_ documented
is that the Vfont_* variables themselves cannot be changed from Lisp,
but that's not what happens in the scenario which I intended to fix.
> If you want to change this behavior, the right way is to look at the
> second patch I provided, which made that change by removing
> Vfont_style_table entirely, fixing both possibilities of disconnecting
> the internal from the Lisp-visible tables.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521;msg=37
That change is too radical, IMO. I saw no need for such radical
changes in an old and stable code, when a simpler, more localized
change would do.
> > so I'd prefer to keep that fix, as it doesn't affect, and isn't
> > affected by, removal of DEFVAR_LISP_NOPRO and defvar_lisp_nopro.
>
> The fix is a workaround to avoid crashes caused by DEFVAR_LISP_NOPRO.
No, it is a fix for a separate problem that is not affected by
DEFVAR_LISP_NOPRO.
> This part was dropped:
>
> This variable cannot be set; trying to do so will signal an error. */);
> Vfont_width_table = BUILD_STYLE_TABLE (width_table);
> make_symbol_constant (intern_c_string ("font-width-table"));
>
> - /* Because the above 3 variables are slots in the vector we create
> - below, and because that vector is staticpro'd, we don't explicitly
> - staticpro the variables, to avoid wasting slots in staticvec[]. */
> staticpro (&font_style_table);
> font_style_table = CALLN (Fvector, Vfont_weight_table, Vfont_slant_table,
> Vfont_width_table);
>
>
> If that wasn't intentional
It wasn't intentional, sorry. I will add that to the patch.
> The alloc.c part was also dropped.
Likewise.
> Your counterproposal is a patch reduced even further, to the point where
> it leaves in two of the four comments telling people to avoid staticpro,
> which they can no longer do. Here, I have to disagree.
Those comments were left in the code by my mistake, I will remove
them.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-30 10:59 ` Eli Zaretskii
@ 2025-01-30 11:52 ` Pip Cet via Emacs development discussions.
2025-01-30 12:35 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-01-30 11:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Thu, 30 Jan 2025 10:41:08 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> > The patch you proposed, like that of Stefan, reverts the fix for a
>>
>> It reverts a hastily-conceived behavior change in font.c which may have
>> reduced some crashes and triggered some others.
>
> There was no haste. You pointed out a problem, and I agreed that it
> was a problem and installed a fix for it.
The problem I pointed out was that DEFVAR_LISP_NOPRO was used
incorrectly. The fix was to use DFEVAR_LISP instead.
So, no, changing behavior in the way you did was not "a fix for it", it
was a separate behavior change which should have been discussed
independently.
You asked me, IIUC, for a review. I pointed out things that should have
been changed before pushing. Instead, you added the problematic comment
and pushed the originally-proposed version. I'm sorry if I
mischaracterized that as "hasty".
>> > separate issue: if font_style_to_value extends the style table, the
>> ^^^^^^^^
>>
>> If it's a separate issue, we should fix it separately.
>
> I did fix it separately. The commit which fixed that didn't touch
> DEFVAR_LISP_NOPRO or defvar_lisp_nopro.
You mean commit 8d471adecef540d49807dad114f7a11fb3fe2a95 ? It includes
a three-line comment specifically about DEFVAR_LISP_NOPRO.
The discussion that led to it was:
Eli > WDYT about the patch below? It's supposed to keep the 3 variables in
Eli > sync with the corresponding slots in font_style_table, if the slots
Eli > are ever modified.
Pip > If you meant to ask whether the patch will momentarily render this
Pip > specific bug harmless, I believe it will (but expose other bugs which
Pip > will still cause crashes).
Eli > I was asking about the problem where that code makes the values of
Eli > Vfont_weight_table and its 2 brethren vulnerable to being GC'ed.
Eli > That's the only problem I tried to solve with that patch.
I read that commit, and this last paragraph, as "the point of this patch
is to solve only one problem, that of GC vulnerability" As this
vulnerability was caused by incorrect use of DEFVAR_LISP_NOPRO, and we
have found a better way of avoiding the vulnerability (use DEFVAR_LISP),
I fail to see what the remaining problems you're trying to solve with
that patch are.
>> > Vfont_* variables keep their old values instead of reflecting the
>> > changes to the style table.
>>
>> Indeed. That's surprising, but documented and the established
>> behavior, and you changed only half of it.
>
> It's neither documented nor established, AFAICT. What _is_ documented
> is that the Vfont_* variables themselves cannot be changed from Lisp,
> but that's not what happens in the scenario which I intended to fix.
Above, you said it was only the GC vulnerability you intended to fix.
>> If you want to change this behavior, the right way is to look at the
>> second patch I provided, which made that change by removing
>> Vfont_style_table entirely, fixing both possibilities of disconnecting
>> the internal from the Lisp-visible tables.
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521;msg=37
>
> That change is too radical, IMO. I saw no need for such radical
Then so is yours.
> changes in an old and stable code, when a simpler, more localized
> change would do.
I can accept that decision. s/_NOPRO//g is that simple, localized change
you're looking for. 8d471adecef540d49807dad114f7a11fb3fe2a95 is not.
>> > so I'd prefer to keep that fix, as it doesn't affect, and isn't
>> > affected by, removal of DEFVAR_LISP_NOPRO and defvar_lisp_nopro.
>>
>> The fix is a workaround to avoid crashes caused by DEFVAR_LISP_NOPRO.
>
> No, it is a fix for a separate problem that is not affected by
> DEFVAR_LISP_NOPRO.
I'm sorry, but given that the commit includes the comment about not
staticproing the variables, the context in which it arose was that of
fixing a GC vulnerability, and there is no bug number for the separate
problem this "fixes", my recommendation (not a request; do things as you
please, obviously) would be to revert it for now, open a bug number,
wait for actual discussion, maybe even take it into account, then push.
> It wasn't intentional, sorry. I will add that to the patch.
No reason to apologize. If you want to propose a compromise with a
corrected patch, that would be excellent and may be a way forward here.
It is my strong impression that this discussion could benefit from the
input of Stefan Kangas, if he has the time and inclination to spend more
time on the matter. But I understand his time is limited and he has to
prioritize things.
So my proposal is for Stefan to briefly ack or nak this; if there's an
ack, I'll wait for his input, even if it's just "can't comment after
all", before responding again.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-30 11:52 ` Pip Cet via Emacs development discussions.
@ 2025-01-30 12:35 ` Eli Zaretskii
2025-02-01 14:21 ` Pip Cet via Emacs development discussions.
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-01-30 12:35 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Thu, 30 Jan 2025 11:52:08 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
> >> Date: Thu, 30 Jan 2025 10:41:08 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
> >>
> >> "Eli Zaretskii" <eliz@gnu.org> writes:
> >>
> >> > The patch you proposed, like that of Stefan, reverts the fix for a
> >>
> >> It reverts a hastily-conceived behavior change in font.c which may have
> >> reduced some crashes and triggered some others.
> >
> > There was no haste. You pointed out a problem, and I agreed that it
> > was a problem and installed a fix for it.
>
> The problem I pointed out was that DEFVAR_LISP_NOPRO was used
> incorrectly. The fix was to use DFEVAR_LISP instead.
Yes, but as part of that discussion the problematic behavior when
font_style_table is modified by the code was raised. The changes I'm
talking about, which I want to keep, were installed to fix that
problem.
> So, no, changing behavior in the way you did was not "a fix for it", it
> was a separate behavior change which should have been discussed
> independently.
Yes, it was a separate behavior change.
> I'm sorry, but given that the commit includes the comment about not
> staticproing the variables, the context in which it arose was that of
> fixing a GC vulnerability, and there is no bug number for the separate
> problem this "fixes", my recommendation (not a request; do things as you
> please, obviously) would be to revert it for now, open a bug number,
> wait for actual discussion, maybe even take it into account, then push.
>
> > It wasn't intentional, sorry. I will add that to the patch.
>
> No reason to apologize. If you want to propose a compromise with a
> corrected patch, that would be excellent and may be a way forward here.
The patch I propose is below. It now removes the two comments I've
missed in the previous proposal.
diff --git a/src/alloc.c b/src/alloc.c
index 9437bed..eb9385a 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7632,9 +7632,7 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0)
/* If the value is forwarded to a buffer or keyboard field,
these are marked when we see the corresponding object.
And if it's forwarded to a C variable, either it's not
- a Lisp_Object var, or it's staticpro'd already, or it's
- reachable from font_style_table which is also
- staticpro'd. */
+ a Lisp_Object var, or it's staticpro'd already. */
break;
default: emacs_abort ();
}
diff --git a/src/font.c b/src/font.c
index dfe479f..a1843bc 100644
--- a/src/font.c
+++ b/src/font.c
@@ -5970,7 +5970,7 @@ syms_of_font (void)
table used by the font display code. So we make them read-only,
to avoid this confusing situation. */
- DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
+ DEFVAR_LISP ("font-weight-table", Vfont_weight_table,
doc: /* Vector of valid font weight values.
Each element has the form:
[NUMERIC-VALUE SYMBOLIC-NAME ALIAS-NAME ...]
@@ -5979,23 +5979,20 @@ syms_of_font (void)
Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
make_symbol_constant (intern_c_string ("font-weight-table"));
- DEFVAR_LISP_NOPRO ("font-slant-table", Vfont_slant_table,
+ DEFVAR_LISP ("font-slant-table", Vfont_slant_table,
doc: /* Vector of font slant symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_slant_table = BUILD_STYLE_TABLE (slant_table);
make_symbol_constant (intern_c_string ("font-slant-table"));
- DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table,
+ DEFVAR_LISP ("font-width-table", Vfont_width_table,
doc: /* Alist of font width symbols vs the corresponding numeric values.
See `font-weight-table' for the format of the vector.
This variable cannot be set; trying to do so will signal an error. */);
Vfont_width_table = BUILD_STYLE_TABLE (width_table);
make_symbol_constant (intern_c_string ("font-width-table"));
- /* Because the above 3 variables are slots in the vector we create
- below, and because that vector is staticpro'd, we don't explicitly
- staticpro the variables, to avoid wasting slots in staticvec[]. */
staticpro (&font_style_table);
font_style_table = CALLN (Fvector, Vfont_weight_table, Vfont_slant_table,
Vfont_width_table);
diff --git a/src/lisp.h b/src/lisp.h
index 98c56e8..5bb05ed 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3780,7 +3780,6 @@ call0 (Lisp_Object fn)
}
extern void defvar_lisp (struct Lisp_Fwd const *, char const *);
-extern void defvar_lisp_nopro (struct Lisp_Fwd const *, char const *);
extern void defvar_bool (struct Lisp_Fwd const *, char const *);
extern void defvar_int (struct Lisp_Fwd const *, char const *);
extern void defvar_kboard (struct Lisp_Fwd const *, char const *);
@@ -3802,12 +3801,7 @@ call0 (Lisp_Object fn)
All C code uses the `cons_cells_consed' name. This is all done
this way to support indirection for multi-threaded Emacs.
- DEFVAR_LISP staticpro's the variable; DEFVAR_LISP_NOPRO does not, and
- is used for variables that are protected in other ways (e.g., because
- they can be accessed from another variable, which is itself
- protected, see font_style_table on font.c as an example). This is
- not used in the HAVE_MPS build, where DEFVAR_LISP_NOPRO is equivalent
- to DEFVAR_LISP. */
+ DEFVAR_LISP staticpro's the variable. */
#define DEFVAR_LISP(lname, vname, doc) \
do { \
@@ -3815,16 +3809,6 @@ #define DEFVAR_LISP(lname, vname, doc) \
= {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \
defvar_lisp (&o_fwd, lname); \
} while (false)
-#ifdef HAVE_MPS
-#define DEFVAR_LISP_NOPRO DEFVAR_LISP
-#else
-#define DEFVAR_LISP_NOPRO(lname, vname, doc) \
- do { \
- static struct Lisp_Fwd const o_fwd \
- = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \
- defvar_lisp_nopro (&o_fwd, lname); \
- } while (false)
-#endif
#define DEFVAR_BOOL(lname, vname, doc) \
do { \
static struct Lisp_Fwd const b_fwd \
diff --git a/src/lread.c b/src/lread.c
index 95ef9fb..e42e3f5 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -5492,25 +5492,15 @@ defvar_bool (struct Lisp_Fwd const *b_fwd, char const *namestring)
}
/* Similar but define a variable whose value is the Lisp Object stored
- at address. Two versions: with and without gc-marking of the C
- variable. The nopro version is used when that variable will be
- gc-marked for some other reason, since marking the same slot twice
- can cause trouble with strings. */
+ at address. */
void
-defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring)
+defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring)
{
eassert (o_fwd->type == Lisp_Fwd_Obj);
Lisp_Object sym = intern_c_string (namestring);
XBARE_SYMBOL (sym)->u.s.declared_special = true;
XBARE_SYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED;
SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd);
-}
-
-void
-defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring)
-{
- eassert (o_fwd->type == Lisp_Fwd_Obj);
- defvar_lisp_nopro (o_fwd, namestring);
staticpro (o_fwd->u.objvar);
}
^ permalink raw reply related [flat|nested] 76+ messages in thread
* igc testing and bug reports -was- Re: Not protecting Lisp objects from GC
2025-01-29 23:09 ` Jeremy Bryant
2025-01-30 5:11 ` Gerd Möllmann
2025-01-30 7:52 ` Eli Zaretskii
@ 2025-01-31 22:48 ` Jeremy Bryant
2025-02-01 8:26 ` Eli Zaretskii
` (2 more replies)
2 siblings, 3 replies; 76+ messages in thread
From: Jeremy Bryant @ 2025-01-31 22:48 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
>>> I am a non-expert in GC.
>>> As such would you have any guidance on how to
>>> understand the benefits of the igc branch
>>
>> I recommend starting with admin/igc.org. I'm not a particularly good
>> explaining things, but I'd hope it's helpful anyway.
>>
>>> and the 'easiest' entry points into the code for study purposes?
>>
>> MPS is a library, so one has to understand its API first; igc.org has
>> links to the MPS documentation. The documentation includes a Guide that
>> I would start with.
>>
>> Once you've done that, read the rest of igc.org, and then see how igc.c
>> uses the API. I'd start here
>>
>> igc.c:
>> 5235 void
>> 5236 init_igc (void)
>> 5237 {
>> 5238 /* Returns previous handler. */
>> 5239 (void) mps_lib_assert_fail_install (igc_assert_fail);
>> 5240 global_igc = make_igc ();
>> 5241 add_main_thread ();
>> 5242 set_state (IGC_STATE_USABLE_PARKED);
>> 5243 }
>>
>> This is called very early when Emacs starts. It sets up everything so
>> that the GC is usable. Follow the call tree and look up MPS API
>> functions being called in the MPS Reference.
>>
>> Then ask questions :-).
>
> Thanks for the detailed description and guide. I will read up and try
> to ask questions.
>
> Furthermore this succinct summary and entry point may
> help guide others now, on the road to this large feature.
I find admin/igc.org very readable, and thanks to the instructions in
README.IGC, have compiled the branch in a straightforward manner (on GNU/Linux)
Questions; There are two sets of instructions, with and without debug.
What is your recommendation with respect to the status of the branch:
Should it be compiled and run under gdb?
Or is it stable enough to run without the debug Can any bug reports be submitted in the usual way with M-x
report-emacs-bug?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: igc testing and bug reports -was- Re: Not protecting Lisp objects from GC
2025-01-31 22:48 ` igc testing and bug reports -was- " Jeremy Bryant
@ 2025-02-01 8:26 ` Eli Zaretskii
2025-02-01 8:53 ` Gerd Möllmann
2025-02-01 9:14 ` Pip Cet via Emacs development discussions.
2 siblings, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-01 8:26 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: gerd.moellmann, emacs-devel
> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Fri, 31 Jan 2025 22:48:53 +0000
>
> Questions; There are two sets of instructions, with and without debug.
> What is your recommendation with respect to the status of the branch:
> Should it be compiled and run under gdb?
I think it's preferable, if you can afford it.
> Or is it stable enough to run without the debug Can any bug reports be submitted in the usual way with M-x
> report-emacs-bug?
"Stable enough" is in the eyes of the beholder, and also depends on
what you are doing in Emacs. Don't forget that this branch is a fork
of the master branch, which itself is not release-level stable.
In any case, bugs on this branch should be reported via
report-emacs-bug, regardless. This is so for any branch in the
repository. Just make sure to remember mentioning the branch in the
bug Subject.
Thanks.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: igc testing and bug reports -was- Re: Not protecting Lisp objects from GC
2025-01-31 22:48 ` igc testing and bug reports -was- " Jeremy Bryant
2025-02-01 8:26 ` Eli Zaretskii
@ 2025-02-01 8:53 ` Gerd Möllmann
2025-02-01 9:14 ` Pip Cet via Emacs development discussions.
2 siblings, 0 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-01 8:53 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Eli Zaretskii, emacs-devel
Jeremy Bryant <jb@jeremybryant.net> writes:
> Questions; There are two sets of instructions, with and without debug.
> What is your recommendation with respect to the status of the branch:
> Should it be compiled and run under gdb?
>
> Or is it stable enough to run without the debug Can any bug reports be submitted in the usual way with M-x
> report-emacs-bug?
That's hard for me to say, because I'm using macOS only.
I'm using my Emacs (= master + other things) with igc, exclusively, for
months without a problem, and I'm using the non-debug version of MPS
from Homebrew.
Wrt reporting bugs I think Eli will have the answer.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: igc testing and bug reports -was- Re: Not protecting Lisp objects from GC
2025-01-31 22:48 ` igc testing and bug reports -was- " Jeremy Bryant
2025-02-01 8:26 ` Eli Zaretskii
2025-02-01 8:53 ` Gerd Möllmann
@ 2025-02-01 9:14 ` Pip Cet via Emacs development discussions.
2 siblings, 0 replies; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-01 9:14 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Gerd Möllmann, Eli Zaretskii, emacs-devel
"Jeremy Bryant" <jb@jeremybryant.net> writes:
>> Thanks for the detailed description and guide. I will read up and try
>> to ask questions.
>>
>> Furthermore this succinct summary and entry point may
>> help guide others now, on the road to this large feature.
>
> I find admin/igc.org very readable, and thanks to the instructions in
> README.IGC, have compiled the branch in a straightforward manner (on GNU/Linux)
Excellent!
> Questions; There are two sets of instructions, with and without debug.
You mean with and without debug builds of MPS?
> What is your recommendation with respect to the status of the branch:
> Should it be compiled and run under gdb?
My recommendation is to always run Emacs under GDB, including production
Emacs versions that you don't expect to see any bugs in.
> Or is it stable enough to run without the debug
Running in GDB won't slow it down, and it makes crashes debuggable. I'd
do it.
> Can any bug reports be submitted in the usual way with M-x
> report-emacs-bug?
Yes, and we'd be most grateful for any and all such reports, even those
where it seems at first not much can be said :-)
Thanks for testing this.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-30 12:35 ` Eli Zaretskii
@ 2025-02-01 14:21 ` Pip Cet via Emacs development discussions.
2025-02-01 14:46 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-01 14:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Thu, 30 Jan 2025 11:52:08 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> >> Date: Thu, 30 Jan 2025 10:41:08 +0000
>> >> From: Pip Cet <pipcet@protonmail.com>
>> >> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>> >>
>> >> "Eli Zaretskii" <eliz@gnu.org> writes:
>> >>
>> >> > The patch you proposed, like that of Stefan, reverts the fix for a
>> >>
>> >> It reverts a hastily-conceived behavior change in font.c which may have
>> >> reduced some crashes and triggered some others.
>> >
>> > There was no haste. You pointed out a problem, and I agreed that it
>> > was a problem and installed a fix for it.
>>
>> The problem I pointed out was that DEFVAR_LISP_NOPRO was used
>> incorrectly. The fix was to use DFEVAR_LISP instead.
>
> Yes, but as part of that discussion the problematic behavior when
> font_style_table is modified by the code was raised. The changes I'm
> talking about, which I want to keep, were installed to fix that
> problem.
Please read this email upside-down. The important bit is at the end;
the rest is just more of the same discussion that interested parties can
find in bug#75521.
I'll address that issue in a bit, but if we can agree it's a *separate*
change, independent of the comment added in the same commit, let's
revert that commit, then reinstall with a commit message which indicates
what we actually did and why. If we want to install it. Which is your
decision, but one I object to:
The fix is bad, and ignores what seem to me to be very good reasons for
the previous behavior.
Old Behavior:
1. a user starts messing about with Vfont_weight_table, removing a
common symbol
2. we need the symol, we fix the problem, but we also take this
opportunity to divorce our internal tables from the ones the user has
modified so no further damage can accumulate.
3. the user continues modifying the tables with no further effect.
New Behavior:
1. a user starts messing about with Vfont_weight_table, removing a
common symbol
2. we need the symbol, so we fix the problem, but we also expose the
fixed table to the user
3. the user continues modifying the fixed table, making our new entries
useless.
4. we go back to 2, which we can do for up to 255 times before hitting
an eassert and crashing Emacs.
I think "my font weight modifications aren't having any effect" is
better than "Emacs crashed because of something I did in Lisp". Of
course, it would be better to fix the font code to avoid encoding Lisp
symbols in bitfields in fixnums and simply use Lisp structures directly.
Also, while a very minor issue, my suggestion is not to use "default:
break;" in a switch statement to indicate that an impossible situation
was detected and Emacs is about to crash or experience massive memory
corruption. I agree emacs_abort () / eassert (0) / eassume (0) may be
too many options to decide between (and Paul suggested adding
emacs_unreachable () ), but silently continuing seems worse than the
other four.
>> So, no, changing behavior in the way you did was not "a fix for it", it
>> was a separate behavior change which should have been discussed
>> independently.
>
> Yes, it was a separate behavior change.
You said:
"I was asking about the problem where that code makes the values of
Vfont_weight_table and its 2 brethren vulnerable to being GC'ed.
That's the only problem I tried to solve with that patch."
I'm sorry, but that left me with the impression that the patch (it's the
same patch) only tried to solve the GC vulnerability problem, rather
than adding a separate behavior change which was never discussed,
AFAICT.
>> I'm sorry, but given that the commit includes the comment about not
>> staticproing the variables, the context in which it arose was that of
>> fixing a GC vulnerability, and there is no bug number for the separate
>> problem this "fixes", my recommendation (not a request; do things as you
>> please, obviously) would be to revert it for now, open a bug number,
>> wait for actual discussion, maybe even take it into account, then push.
>>
>> > It wasn't intentional, sorry. I will add that to the patch.
>>
>> No reason to apologize. If you want to propose a compromise with a
>> corrected patch, that would be excellent and may be a way forward here.
>
> The patch I propose is below. It now removes the two comments I've
> missed in the previous proposal.
Important bit here:
Let's go with that. It's not Stefan Kangas's proposal (which was to
revert the problematic changes on master). It reverts only some of the
problematic changes, and only on a feature branch, and most likely it'll
cause a merge conflict if feature/igc is ever merged, but it seems clear
from the discussion that it's your best offer.
Since I would like to see feature/igc merged, I'll take it. I'll live
with the behavior change introduced in font.c since I don't use that
file much and hope someone will spend more time on it. I hope that the
discussion was sufficiently annoying that no one will be tempted to
introduce new uses of DEFVAR_LISP_NOPRO on master, but at least
feature/igc will break and we'll become aware of such developments.
I can't speak for Stefan Kangas, but I would be delighted if you could
push the patch you propose to feature/igc. Thank you.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-01 14:21 ` Pip Cet via Emacs development discussions.
@ 2025-02-01 14:46 ` Eli Zaretskii
2025-02-01 15:06 ` Pip Cet via Emacs development discussions.
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-01 14:46 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Sat, 01 Feb 2025 14:21:01 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
> > Yes, but as part of that discussion the problematic behavior when
> > font_style_table is modified by the code was raised. The changes I'm
> > talking about, which I want to keep, were installed to fix that
> > problem.
>
> Please read this email upside-down. The important bit is at the end;
> the rest is just more of the same discussion that interested parties can
> find in bug#75521.
> > The patch I propose is below. It now removes the two comments I've
> > missed in the previous proposal.
>
> Important bit here:
>
> Let's go with that. It's not Stefan Kangas's proposal (which was to
> revert the problematic changes on master). It reverts only some of the
> problematic changes, and only on a feature branch, and most likely it'll
> cause a merge conflict if feature/igc is ever merged, but it seems clear
> from the discussion that it's your best offer.
>
> I can't speak for Stefan Kangas, but I would be delighted if you could
> push the patch you propose to feature/igc.
Done.
> I'll address that issue in a bit, but if we can agree it's a *separate*
> change, independent of the comment added in the same commit, let's
> revert that commit, then reinstall with a commit message which indicates
> what we actually did and why. If we want to install it. Which is your
> decision, but one I object to:
The commit log for that change says:
* src/font.c (font_style_to_value): Update the Vfont_* variables
to keep them in sync with their slots in 'font_style_table'.
(Bug#75521)
It also says:
(syms_of_font): Comment on usage of DEFVAR_LISP_NOPRO.
(which is not related to the bug number, mind), but since the macro is
now removed, what would be the point of reverting and reapplying? Why
does it matter how a deleted macro was used?
> The fix is bad, and ignores what seem to me to be very good reasons for
> the previous behavior.
>
>
> Old Behavior:
>
> 1. a user starts messing about with Vfont_weight_table, removing a
> common symbol
>
> 2. we need the symol, we fix the problem, but we also take this
> opportunity to divorce our internal tables from the ones the user has
> modified so no further damage can accumulate.
>
> 3. the user continues modifying the tables with no further effect.
>
>
>
> New Behavior:
>
> 1. a user starts messing about with Vfont_weight_table, removing a
> common symbol
>
> 2. we need the symbol, so we fix the problem, but we also expose the
> fixed table to the user
>
> 3. the user continues modifying the fixed table, making our new entries
> useless.
>
> 4. we go back to 2, which we can do for up to 255 times before hitting
> an eassert and crashing Emacs.
I don't understand what you mean by "user messing with Vfont_*
variables". Those variables are read-only, so neither the user nor
any Lisp program can change their values.
The change I installed was not about users messing with Vfont_*
variables, it was for the opposite situation: when font_style_to_value
modified the slots of the style table as side effect of its code, it
did not update the Vfont_* variables to reflect those changes.
When I installed the patch, it fixed two separate problems: (a) the
old value of Vfont_* were left unprotected from GC, and (b) the
changes to the style table were not propagated to the Vfont_*
variables. The first part is now fixed by using DEFVAR_LISP for the
variables, but the second part still needs to be done.
> I think "my font weight modifications aren't having any effect" is
> better than "Emacs crashed because of something I did in Lisp".
Yes, except that I don't see how this can happen, because the user
cannot change Vfont_* variables, right?
> Also, while a very minor issue, my suggestion is not to use "default:
> break;" in a switch statement to indicate that an impossible situation
> was detected and Emacs is about to crash or experience massive memory
> corruption. I agree emacs_abort () / eassert (0) / eassume (0) may be
> too many options to decide between (and Paul suggested adding
> emacs_unreachable () ), but silently continuing seems worse than the
> other four.
That's a separate issue. When we have decided what to do in these
cases, I'm okay with applying that decision to the code in
font_style_to_value, whether it's emacs_abort or eassume or anything
else.
> > Yes, it was a separate behavior change.
>
> You said:
>
> "I was asking about the problem where that code makes the values of
> Vfont_weight_table and its 2 brethren vulnerable to being GC'ed.
> That's the only problem I tried to solve with that patch."
>
> I'm sorry, but that left me with the impression that the patch (it's the
> same patch) only tried to solve the GC vulnerability problem, rather
> than adding a separate behavior change which was never discussed,
> AFAICT.
It fixed both, and I apologize for my inaccurate wording.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-01 14:46 ` Eli Zaretskii
@ 2025-02-01 15:06 ` Pip Cet via Emacs development discussions.
2025-02-01 15:34 ` Eli Zaretskii
0 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-01 15:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> I think "my font weight modifications aren't having any effect" is
>> better than "Emacs crashed because of something I did in Lisp".
>
> Yes, except that I don't see how this can happen, because the user
> cannot change Vfont_* variables, right?
They're vectors. All Emacs vectors but zero_vector, as of today, can be
modified by Lisp. You can't reassign some variables directly, but you
can modify the objects they refer to.
If the only reason we have those extra variables is to let Lisp know
about the tables, maybe we should export deep copies of them, not the
original objects?
But, again, let's discuss this with whoever has time to look at font.c
up closely.
>> Also, while a very minor issue, my suggestion is not to use "default:
>> break;" in a switch statement to indicate that an impossible situation
>> was detected and Emacs is about to crash or experience massive memory
>> corruption. I agree emacs_abort () / eassert (0) / eassume (0) may be
>> too many options to decide between (and Paul suggested adding
>> emacs_unreachable () ), but silently continuing seems worse than the
>> other four.
>
> That's a separate issue.
Agreed. Let's wait for that.
>> > Yes, it was a separate behavior change.
>>
>> You said:
>>
>> "I was asking about the problem where that code makes the values of
>> Vfont_weight_table and its 2 brethren vulnerable to being GC'ed.
>> That's the only problem I tried to solve with that patch."
>>
>> I'm sorry, but that left me with the impression that the patch (it's the
>> same patch) only tried to solve the GC vulnerability problem, rather
>> than adding a separate behavior change which was never discussed,
>> AFAICT.
>
> It fixed both, and I apologize for my inaccurate wording.
Thank you. In turn, I would like to apologize for what probably seemed
like pointless pedantry there. My mind is somewhat unusual at the best
of times and I sometimes genuinely fail to see things that are obvious
to others.
I'll push the GTK/X changes to feature/igc now.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-01 15:06 ` Pip Cet via Emacs development discussions.
@ 2025-02-01 15:34 ` Eli Zaretskii
0 siblings, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-01 15:34 UTC (permalink / raw)
To: Pip Cet; +Cc: stefankangas, gerd.moellmann, emacs-devel
> Date: Sat, 01 Feb 2025 15:06:04 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: stefankangas@gmail.com, gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
> >> I think "my font weight modifications aren't having any effect" is
> >> better than "Emacs crashed because of something I did in Lisp".
> >
> > Yes, except that I don't see how this can happen, because the user
> > cannot change Vfont_* variables, right?
>
> They're vectors. All Emacs vectors but zero_vector, as of today, can be
> modified by Lisp. You can't reassign some variables directly, but you
> can modify the objects they refer to.
>
> If the only reason we have those extra variables is to let Lisp know
> about the tables, maybe we should export deep copies of them, not the
> original objects?
>
> But, again, let's discuss this with whoever has time to look at font.c
> up closely.
Agreed.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-01-27 9:08 Not protecting Lisp objects from GC Gerd Möllmann
2025-01-27 9:46 ` Stefan Kangas
2025-01-27 13:01 ` Eli Zaretskii
@ 2025-02-03 19:24 ` Pip Cet via Emacs development discussions.
2025-02-03 20:14 ` Eli Zaretskii
2 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-03 19:24 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Emacs Devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> I'm talking about the old GC, and it is _bad_ to not protect GC'able
> objects because
>
> - they are protected from GC by being referenced from other objects that
> we '"know" are protected from GC
>
> - because a GC "cannot happen"
>
> And there are _no_ exceptions.
My reading of this is that Gerd made a very concrete proposal to change
Emacs code here; there was a lot of discussion, but there was never a
final decision on this proposal.
I am, of course, wildly in favor of Gerd's proposal! While one reason
for that is that it would make work on feature/igc easier, I also see
benefits for those systems which will continue to use alloc.c for a
while after when(*) feature/igc is merged.
Whatever the decision is, whether it's to apply Gerd's no-exceptions
rule to new code, old and new code, or not to apply it at all for now, I
can live with it. But I need to know which it is. (And, if it's the
latter, how long "for now" is supposed to be.)
This isn't just academic: if we decide to go with Gerd's proposal, the
remaining "correctness bug" part of bug#75754 will be fixed in the new
way, as my patch there proposes. If we don't, we'll have to wait for
someone to fix it in the existing way.
None of this affects the existing three uses of DEFVAR_LISP_NOPRO, which
will remain on master until feature/igc is merged and hopefully removes
it (or until font.c is fixed no longer to require it, whichever comes
first). It also doesn't affect SDATA pointer validity across GC and
conservatively scanning SAFE_ALLOCA'd memory.
If we accept Gerd's proposal, and you put an unprotected pointer, SDATA
pointer or Lisp_Object in SAFE_ALLOCA'd memory or worse, your code will
have to be fixed, and "GC cannot happen" is not an excuse. No
exceptions.
(*) I consider a feature/igc merge in the foreseable future likely
enough I'll use "when" here.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-03 19:24 ` Pip Cet via Emacs development discussions.
@ 2025-02-03 20:14 ` Eli Zaretskii
2025-02-03 21:07 ` Pip Cet via Emacs development discussions.
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-03 20:14 UTC (permalink / raw)
To: Pip Cet; +Cc: gerd.moellmann, emacs-devel
> Date: Mon, 03 Feb 2025 19:24:07 +0000
> Cc: Emacs Devel <emacs-devel@gnu.org>
> From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> > I'm talking about the old GC, and it is _bad_ to not protect GC'able
> > objects because
> >
> > - they are protected from GC by being referenced from other objects that
> > we '"know" are protected from GC
> >
> > - because a GC "cannot happen"
> >
> > And there are _no_ exceptions.
>
> My reading of this is that Gerd made a very concrete proposal to change
> Emacs code here; there was a lot of discussion, but there was never a
> final decision on this proposal.
I didn't see a concrete proposal, I saw a principle (with which I
agreed).
> This isn't just academic: if we decide to go with Gerd's proposal, the
> remaining "correctness bug" part of bug#75754 will be fixed in the new
> way, as my patch there proposes. If we don't, we'll have to wait for
> someone to fix it in the existing way.
>
> None of this affects the existing three uses of DEFVAR_LISP_NOPRO, which
> will remain on master until feature/igc is merged and hopefully removes
> it (or until font.c is fixed no longer to require it, whichever comes
> first). It also doesn't affect SDATA pointer validity across GC and
> conservatively scanning SAFE_ALLOCA'd memory.
In bug#75754 we installed one fix, which wasn't enough, then you
proposed 3 alternatives for the second related bug, of which I
preferred the second alternative. Is there any problem with
installing that now?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-03 20:14 ` Eli Zaretskii
@ 2025-02-03 21:07 ` Pip Cet via Emacs development discussions.
2025-02-04 4:17 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-03 21:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Mon, 03 Feb 2025 19:24:07 +0000
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>> > I'm talking about the old GC, and it is _bad_ to not protect GC'able
>> > objects because
>> >
>> > - they are protected from GC by being referenced from other objects that
>> > we '"know" are protected from GC
>> >
>> > - because a GC "cannot happen"
>> >
>> > And there are _no_ exceptions.
>>
>> My reading of this is that Gerd made a very concrete proposal to change
>> Emacs code here; there was a lot of discussion, but there was never a
>> final decision on this proposal.
>
> I didn't see a concrete proposal, I saw a principle (with which I
> agreed).
Gerd, could you please comment and (if I'm right) rephrase it as a more
concrete proposal? It would help me a lot if there were a concrete
resolution here.
(Bug#75754 has been resolved now, after the usual last-minute "oops,
missed this". Sorry, Eli, I had misremembered the state of that
conversation.)
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-03 21:07 ` Pip Cet via Emacs development discussions.
@ 2025-02-04 4:17 ` Gerd Möllmann
2025-02-04 5:22 ` Gerd Möllmann
2025-02-04 16:31 ` Eli Zaretskii
0 siblings, 2 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-04 4:17 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, emacs-devel
Pip Cet <pipcet@protonmail.com> writes:
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
>>> Date: Mon, 03 Feb 2025 19:24:07 +0000
>>> Cc: Emacs Devel <emacs-devel@gnu.org>
>>> From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
>>>
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>>> > I'm talking about the old GC, and it is _bad_ to not protect GC'able
>>> > objects because
>>> >
>>> > - they are protected from GC by being referenced from other objects that
>>> > we '"know" are protected from GC
>>> >
>>> > - because a GC "cannot happen"
>>> >
>>> > And there are _no_ exceptions.
>>>
>>> My reading of this is that Gerd made a very concrete proposal to change
>>> Emacs code here; there was a lot of discussion, but there was never a
>>> final decision on this proposal.
>>
>> I didn't see a concrete proposal, I saw a principle (with which I
>> agreed).
>
> Gerd, could you please comment and (if I'm right) rephrase it as a more
> concrete proposal? It would help me a lot if there were a concrete
> resolution here.
Maybe we can come up with concrete rules together. Without having had a
coffee yet, I would start with
1. All global variables of type Lisp_Object must be a root (staticpro).
2. Storing Lisp_Objects, or the pointers they contain like struct frame,
in malloc'd memory is verboten. That's also true for memory from the
SAFE_ALLOCA macro family because they can malloc.
3. Something has to be done for the SDATA of strings, but I'm not sure
what the current state of affairs is in this regard. In some branch I
think I've seem something already happened WRT pin_string? Don't want
to look it up now when Pip knows for sure :-).
The problem is string compaction. The goal is to pin strings, i.e.
make them immovable, while a pointer into string data is on the
control stack. This includes interior pointers.
Possible rule: Treat pointers into string data like pointers to Lisp
objects. Don't put them in malloc'd memory.
it's a start, I'm sure I've forgotten something.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 4:17 ` Gerd Möllmann
@ 2025-02-04 5:22 ` Gerd Möllmann
2025-02-04 16:22 ` Eli Zaretskii
2025-02-04 16:31 ` Eli Zaretskii
1 sibling, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-04 5:22 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Maybe we can come up with concrete rules together. Without having had a
> coffee yet, I would start with
>
> 1. All global variables of type Lisp_Object must be a root
> (staticpro).
+= No global variables of pointer to some Lisp object, like struct frame
or struct window. Just remembered that I found something like that with
ASAN in the past.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 5:22 ` Gerd Möllmann
@ 2025-02-04 16:22 ` Eli Zaretskii
0 siblings, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-04 16:22 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: pipcet, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 04 Feb 2025 06:22:04 +0100
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> > Maybe we can come up with concrete rules together. Without having had a
> > coffee yet, I would start with
> >
> > 1. All global variables of type Lisp_Object must be a root
> > (staticpro).
>
> += No global variables of pointer to some Lisp object, like struct frame
> or struct window.
Why not?
We do have a few of those, try
$ grep "^\(static \)\?struct frame *" *.c
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 4:17 ` Gerd Möllmann
2025-02-04 5:22 ` Gerd Möllmann
@ 2025-02-04 16:31 ` Eli Zaretskii
2025-02-04 18:17 ` Pip Cet via Emacs development discussions.
1 sibling, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-04 16:31 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: pipcet, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 04 Feb 2025 05:17:01 +0100
>
> 1. All global variables of type Lisp_Object must be a root (staticpro).
>
> 2. Storing Lisp_Objects, or the pointers they contain like struct frame,
> in malloc'd memory is verboten. That's also true for memory from the
> SAFE_ALLOCA macro family because they can malloc.
>
> 3. Something has to be done for the SDATA of strings, but I'm not sure
> what the current state of affairs is in this regard. In some branch I
> think I've seem something already happened WRT pin_string? Don't want
> to look it up now when Pip knows for sure :-).
>
> The problem is string compaction. The goal is to pin strings, i.e.
> make them immovable, while a pointer into string data is on the
> control stack. This includes interior pointers.
>
> Possible rule: Treat pointers into string data like pointers to Lisp
> objects. Don't put them in malloc'd memory.
>
> it's a start, I'm sure I've forgotten something.
For 2 and 3, we must have some macros or template for dealing with
situations where something like that would be needed. Similar to
SAFE_ALLOCA and AUTO_STRING. E.g., how about some macro or function
that would pin a Lisp object and/or its data, so that GC leaves it
alone? Just saying this is "verboten" will not do, because it would
make coding in C for Emacs unbearably hard and error-prone, let alone
practically impossible. How can we expect all Emacs hackers to always
know whether some data they are working with is malloced or not?
And we really do NOT want to make our sources full of code snippets
that copy data to and fro.
So if we adopt these principles, we should make following them humanly
possibly by providing the necessary infrastructure. For starters, how
about each time we see some technique like those we want to abolish,
we try to generalize and produce some useful infrastructure for
dealing with similar situations, instead of each time coding some
ad-hoc solution?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 16:31 ` Eli Zaretskii
@ 2025-02-04 18:17 ` Pip Cet via Emacs development discussions.
2025-02-04 19:55 ` Eli Zaretskii
2025-02-04 21:08 ` Gerd Möllmann
0 siblings, 2 replies; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-04 18:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gerd Möllmann, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Tue, 04 Feb 2025 05:17:01 +0100
>>
>> 1. All global variables of type Lisp_Object must be a root (staticpro).
>> 2. Storing Lisp_Objects, or the pointers they contain like struct frame,
>> in malloc'd memory is verboten. That's also true for memory from the
>> SAFE_ALLOCA macro family because they can malloc.
I'm not sure about this point. Are you saying we should turn all mixed
Lisp/non-Lisp structures into pseudovectors? I'd like that a lot, but
it'd also be a lot of work.
>> 3. Something has to be done for the SDATA of strings, but I'm not sure
>> what the current state of affairs is in this regard. In some branch I
>> think I've seem something already happened WRT pin_string? Don't want
>> to look it up now when Pip knows for sure :-).
I'm not sure what the question is here. I've proposed (and written
code) to make SDATA variables pin their respective sdata (well, the
entire sblocks) on traditional GC. My impression was that we don't want
to do that. (It's unclear whether we'd have to keep "pinned" strings
for performance reasons, but pinning them would no longer be required
for correctness).
I've also proposed (and not written code for the traditional GC) to scan
SAFE_ALLOCA memory like we do the stack. Such memory areas can be very
large, and that might make GC so slow we should detect this situation
and wait for a better time. My impression was that we don't want to do
that, either.
>> The problem is string compaction. The goal is to pin strings, i.e.
>> make them immovable, while a pointer into string data is on the
>> control stack. This includes interior pointers.
I have code to do that; it pins entire sblocks at a time whenever an
SDATA pointer (interior or not) is on the stack/in the registers, and it
does introduce some minimal reordering of strings (they get compacted
"around" the pinned blocks), but it works and shouldn't be slower than
what we have now. Unless, that is, we get rid of pin_string: it's no
longer needed for correctness with my code, but all these extra strings
subject to compaction may slow down things a lot.
>> Possible rule: Treat pointers into string data like pointers to Lisp
>> objects. Don't put them in malloc'd memory.
I think the main code affected is the code building argv and envp in
call_process. I think it'd be cleaner not to have the pointers in those
arrays point to Lisp data, and it'd be faster to do all that on the
stack, but right now we do some of it on the stack and some of it in
xmalloc'd memory so it's not clear to me what the guiding principle is
there.
>> it's a start, I'm sure I've forgotten something.
I think you've forgotten that while SDATA pointers on feature/igc
currently point to non-barriered memory, that's probably less efficient
than keeping short strings next to their string data in AMC pools, and
then we need to find a solution for that. Post-merge, though.
> For 2 and 3, we must have some macros or template for dealing with
> situations where something like that would be needed. Similar to
> SAFE_ALLOCA and AUTO_STRING.
Why a new macro? We have "SDATA", and we could define it, similar to
SAFE_ALLOCA, to pin string data while its automatic variable is on the
stack or until the function exits (locally or not), whichever happens
sooner.
feature/igc wouldn't care about function exits, it'd just use
conservative scanning to keep the sdata alive.
alloc.c could use the specpdl and wouldn't care about the stack variable
at all.
The main syntactic baggage is the SAFE_FREE / USE_SAFE_ALLOCA stuff.
(I'm not sure we even warn about a missed SAFE_FREE, though?)
Yes, some places return SDATA pointers. They shouldn't.
I'd consider making it so SDATA always refers to a *snapshot* of the
string data. If Lisp modifies a string and there's an SDATA pointer to
it, we'll just have to allocate a new SDATA structure and orphan the old
one.
But if the point is to get rid of some no-GC assumptions by changing how
SDATA behaves, I'm all for it, even if the new API isn't the one I would
have chosen.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 18:17 ` Pip Cet via Emacs development discussions.
@ 2025-02-04 19:55 ` Eli Zaretskii
2025-02-04 21:14 ` Gerd Möllmann
2025-02-04 21:08 ` Gerd Möllmann
1 sibling, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-04 19:55 UTC (permalink / raw)
To: Pip Cet; +Cc: gerd.moellmann, emacs-devel
> > For 2 and 3, we must have some macros or template for dealing with
> > situations where something like that would be needed. Similar to
> > SAFE_ALLOCA and AUTO_STRING.
>
> Why a new macro? We have "SDATA", and we could define it, similar to
> SAFE_ALLOCA, to pin string data while its automatic variable is on the
> stack or until the function exits (locally or not), whichever happens
> sooner.
Item 2 is not just about strings.
And anyway, SDATA is not the complete solution, as you yourself say.
It's perhaps the beginning of a solution. I would like us to have an
easy-to-use template for such cases, so that quick review of the code
could easily detect whether the template is or isn't being followed.
> feature/igc wouldn't care about function exits, it'd just use
> conservative scanning to keep the sdata alive.
>
> alloc.c could use the specpdl and wouldn't care about the stack variable
> at all.
>
> The main syntactic baggage is the SAFE_FREE / USE_SAFE_ALLOCA stuff.
> (I'm not sure we even warn about a missed SAFE_FREE, though?)
>
> Yes, some places return SDATA pointers. They shouldn't.
>
> I'd consider making it so SDATA always refers to a *snapshot* of the
> string data. If Lisp modifies a string and there's an SDATA pointer to
> it, we'll just have to allocate a new SDATA structure and orphan the old
> one.
>
> But if the point is to get rid of some no-GC assumptions by changing how
> SDATA behaves, I'm all for it, even if the new API isn't the one I would
> have chosen.
I'm afraid you lost me here. There's some gap here between what Gerd
wrote and the details you describe, and I cannot cross that gap.
In any case, I wasn't talking about any details, just about the
principles and how we could adhere to them in practice without too
much blood, sweat and tears.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 18:17 ` Pip Cet via Emacs development discussions.
2025-02-04 19:55 ` Eli Zaretskii
@ 2025-02-04 21:08 ` Gerd Möllmann
2025-02-05 12:20 ` Eli Zaretskii
1 sibling, 1 reply; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-04 21:08 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, emacs-devel
Pip Cet <pipcet@protonmail.com> writes:
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>> Date: Tue, 04 Feb 2025 05:17:01 +0100
>>>
>>> 1. All global variables of type Lisp_Object must be a root (staticpro).
>
>>> 2. Storing Lisp_Objects, or the pointers they contain like struct frame,
>>> in malloc'd memory is verboten. That's also true for memory from the
>>> SAFE_ALLOCA macro family because they can malloc.
>
> I'm not sure about this point. Are you saying we should turn all mixed
> Lisp/non-Lisp structures into pseudovectors? I'd like that a lot, but
> it'd also be a lot of work.
We could invent something for that. First thing that comes to my mind is
to do as we do in igc, mallocs + make the memory a root that is scanned
(conservatively (mark_memory) or exactly). Without doing something,
putting something in malloc'd memory is unsafe in principle.
>>> 3. Something has to be done for the SDATA of strings, but I'm not sure
>>> what the current state of affairs is in this regard. In some branch I
>>> think I've seem something already happened WRT pin_string? Don't want
>>> to look it up now when Pip knows for sure :-).
>
> I'm not sure what the question is here. I've proposed (and written
> code) to make SDATA variables pin their respective sdata (well, the
> entire sblocks) on traditional GC. My impression was that we don't want
> to do that. (It's unclear whether we'd have to keep "pinned" strings
> for performance reasons, but pinning them would no longer be required
> for correctness).
It's just that I haven't been following development very closely. I
don't know what the state currently is.
> I've also proposed (and not written code for the traditional GC) to scan
> SAFE_ALLOCA memory like we do the stack. Such memory areas can be very
> large, and that might make GC so slow we should detect this situation
> and wait for a better time. My impression was that we don't want to do
> that, either.
Well, that's not the SDATA case, or is it? I wrote something to that
above, the special allocation functions and so on.
>>> The problem is string compaction. The goal is to pin strings, i.e.
>>> make them immovable, while a pointer into string data is on the
>>> control stack. This includes interior pointers.
>
> I have code to do that; it pins entire sblocks at a time whenever an
> SDATA pointer (interior or not) is on the stack/in the registers, and it
> does introduce some minimal reordering of strings (they get compacted
> "around" the pinned blocks), but it works and shouldn't be slower than
> what we have now. Unless, that is, we get rid of pin_string: it's no
> longer needed for correctness with my code, but all these extra strings
> subject to compaction may slow down things a lot.
>
>>> Possible rule: Treat pointers into string data like pointers to Lisp
>>> objects. Don't put them in malloc'd memory.
>
> I think the main code affected is the code building argv and envp in
> call_process. I think it'd be cleaner not to have the pointers in those
> arrays point to Lisp data, and it'd be faster to do all that on the
> stack, but right now we do some of it on the stack and some of it in
> xmalloc'd memory so it's not clear to me what the guiding principle is
> there.
>
>>> it's a start, I'm sure I've forgotten something.
>
> I think you've forgotten that while SDATA pointers on feature/igc
> currently point to non-barriered memory, that's probably less efficient
> than keeping short strings next to their string data in AMC pools, and
> then we need to find a solution for that. Post-merge, though.
I'm sorry, but I don't see a rule here that could be derived from that.
If everything in the SDATA department is as it was when I last looked,
then a rule could be (I don't say it is), that taking SDATA out of a
string can only be done with GC inhibited for the old GC. I guess one
could check that somehow.
Or force the SDATA pointer onto the bindings stack so that GC could see
it. And pin them until an unbind is done happens.
Just ideas. I don't think we currently have the mechanism.
I think the rule here is that using SDATA, passing it other functions,
and so on, is unsafe in principle, and in lack of a mechanism there is
currently no recipe to follow.
>> For 2 and 3, we must have some macros or template for dealing with
>> situations where something like that would be needed. Similar to
>> SAFE_ALLOCA and AUTO_STRING.
>
> Why a new macro? We have "SDATA", and we could define it, similar to
> SAFE_ALLOCA, to pin string data while its automatic variable is on the
> stack or until the function exits (locally or not), whichever happens
> sooner.
>
> feature/igc wouldn't care about function exits, it'd just use
> conservative scanning to keep the sdata alive.
>
> alloc.c could use the specpdl and wouldn't care about the stack variable
> at all.
For example, yes.
> The main syntactic baggage is the SAFE_FREE / USE_SAFE_ALLOCA stuff.
> (I'm not sure we even warn about a missed SAFE_FREE, though?)
>
> Yes, some places return SDATA pointers. They shouldn't.
>
> I'd consider making it so SDATA always refers to a *snapshot* of the
> string data. If Lisp modifies a string and there's an SDATA pointer to
> it, we'll just have to allocate a new SDATA structure and orphan the old
> one.
>
> But if the point is to get rid of some no-GC assumptions by changing how
> SDATA behaves, I'm all for it, even if the new API isn't the one I would
> have chosen.
>
> Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 19:55 ` Eli Zaretskii
@ 2025-02-04 21:14 ` Gerd Möllmann
0 siblings, 0 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-04 21:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Pip Cet, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> > For 2 and 3, we must have some macros or template for dealing with
>> > situations where something like that would be needed. Similar to
>> > SAFE_ALLOCA and AUTO_STRING.
>>
>> Why a new macro? We have "SDATA", and we could define it, similar to
>> SAFE_ALLOCA, to pin string data while its automatic variable is on the
>> stack or until the function exits (locally or not), whichever happens
>> sooner.
>
> Item 2 is not just about strings.
>
> And anyway, SDATA is not the complete solution, as you yourself say.
> It's perhaps the beginning of a solution. I would like us to have an
> easy-to-use template for such cases, so that quick review of the code
> could easily detect whether the template is or isn't being followed.
Right, and where possible, compiler warnings or better yet errors. For
example, that one can get and use string data only in a way that
automatically makes sure it's safe. Just fantasizing: Maybe using a
function char *get_string_data (Lisp_Object string, specpdl_ref count)
that pins the string data until the binding stack is unwound. Or inhibits
GC until then, or what other ideas there might be.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-04 21:08 ` Gerd Möllmann
@ 2025-02-05 12:20 ` Eli Zaretskii
2025-02-05 13:38 ` Gerd Möllmann
0 siblings, 1 reply; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-05 12:20 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: pipcet, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 04 Feb 2025 22:08:52 +0100
>
> I think the rule here is that using SDATA, passing it other functions,
> and so on, is unsafe in principle
But what's the alternative? we cannot possibly copy to some buffer
data of each Lisp string we want to pass to a function, can we?
Because that would be extremely slow, especially for very large
strings. If we need to do something like that, coding for Emacs would
be unbearably hard. We will, in effect, need to invent a whole new
dialect of C.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-05 12:20 ` Eli Zaretskii
@ 2025-02-05 13:38 ` Gerd Möllmann
2025-02-05 14:35 ` Eli Zaretskii
2025-02-05 17:09 ` Pip Cet via Emacs development discussions.
0 siblings, 2 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-05 13:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: pipcet, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Tue, 04 Feb 2025 22:08:52 +0100
>>
>> I think the rule here is that using SDATA, passing it other functions,
>> and so on, is unsafe in principle
>
> But what's the alternative? we cannot possibly copy to some buffer
> data of each Lisp string we want to pass to a function, can we?
> Because that would be extremely slow, especially for very large
> strings. If we need to do something like that, coding for Emacs would
> be unbearably hard. We will, in effect, need to invent a whole new
> dialect of C.
The alternative is to make string data use safe by providing a mechanism
that does that. Emacs doesn't have such a mechanism yet. I proposed
a simple one using the binding stack.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-05 13:38 ` Gerd Möllmann
@ 2025-02-05 14:35 ` Eli Zaretskii
2025-02-05 17:09 ` Pip Cet via Emacs development discussions.
1 sibling, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-05 14:35 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: pipcet, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com, emacs-devel@gnu.org
> Date: Wed, 05 Feb 2025 14:38:08 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >> Date: Tue, 04 Feb 2025 22:08:52 +0100
> >>
> >> I think the rule here is that using SDATA, passing it other functions,
> >> and so on, is unsafe in principle
> >
> > But what's the alternative? we cannot possibly copy to some buffer
> > data of each Lisp string we want to pass to a function, can we?
> > Because that would be extremely slow, especially for very large
> > strings. If we need to do something like that, coding for Emacs would
> > be unbearably hard. We will, in effect, need to invent a whole new
> > dialect of C.
>
> The alternative is to make string data use safe by providing a mechanism
> that does that. Emacs doesn't have such a mechanism yet. I proposed
> a simple one using the binding stack.
Sure, if we can add such a mechanism, and its use is reasonably simple
and not too expensive, that'd be great.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-05 13:38 ` Gerd Möllmann
2025-02-05 14:35 ` Eli Zaretskii
@ 2025-02-05 17:09 ` Pip Cet via Emacs development discussions.
2025-02-05 20:20 ` Gerd Möllmann
1 sibling, 1 reply; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-05 17:09 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>> Date: Tue, 04 Feb 2025 22:08:52 +0100
>>>
>>> I think the rule here is that using SDATA, passing it other functions,
>>> and so on, is unsafe in principle
>>
>> But what's the alternative? we cannot possibly copy to some buffer
>> data of each Lisp string we want to pass to a function, can we?
>> Because that would be extremely slow, especially for very large
>> strings. If we need to do something like that, coding for Emacs would
>> be unbearably hard. We will, in effect, need to invent a whole new
>> dialect of C.
>
> The alternative is to make string data use safe by providing a mechanism
> that does that. Emacs doesn't have such a mechanism yet. I proposed
> a simple one using the binding stack.
Sure, we can use the binding stack, but the easier way for most SDATA
pointers is to scan the stack conservatively for valid SDATA pointers
and use those to keep the respective sblocks pinned during the GC cycle.
I've done this quite a while ago, it works! There is a potential issue
with very large strings on 32-bit systems, because a large range of
words would be interpreted as potentially keeping the string alive and
it might never be collected.
I don't know whether we actually ever need to put SDATA pointers in
xmalloc'd memory; but if we also scanned SAFE_ALLOCA'd memory, we could
put the SDATA pointers there, essentially removing the need for no-GC
assumptions.
That second part wouldn't be hard to do either, but I was told not to
waste my time so I didn't do it yet.
Pip
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-05 17:09 ` Pip Cet via Emacs development discussions.
@ 2025-02-05 20:20 ` Gerd Möllmann
2025-02-05 20:54 ` [Ext]Re: " Edward Reingold
2025-02-06 0:12 ` Pip Cet via Emacs development discussions.
0 siblings, 2 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-05 20:20 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, emacs-devel
Pip Cet <pipcet@protonmail.com> writes:
>> The alternative is to make string data use safe by providing a mechanism
>> that does that. Emacs doesn't have such a mechanism yet. I proposed
>> a simple one using the binding stack.
>
> Sure, we can use the binding stack, but the easier way for most SDATA
> pointers is to scan the stack conservatively for valid SDATA pointers
> and use those to keep the respective sblocks pinned during the GC
> cycle.
Or that, even better!
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [Ext]Re: Not protecting Lisp objects from GC
2025-02-05 20:20 ` Gerd Möllmann
@ 2025-02-05 20:54 ` Edward Reingold
2025-02-06 8:01 ` Eli Zaretskii
2025-02-06 0:12 ` Pip Cet via Emacs development discussions.
1 sibling, 1 reply; 76+ messages in thread
From: Edward Reingold @ 2025-02-05 20:54 UTC (permalink / raw)
To: Gerd Möllmann, Pip Cet; +Cc: Eli Zaretskii, emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
How do I unsubscribe from this?
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: emacs-devel-bounces+reingold=iit.edu@gnu.org <emacs-devel-bounces+reingold=iit.edu@gnu.org> on behalf of Gerd Möllmann <gerd.moellmann@gmail.com>
Sent: Wednesday, February 5, 2025 2:20:41 PM
To: Pip Cet <pipcet@protonmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Subject: [Ext]Re: Not protecting Lisp objects from GC
Pip Cet <pipcet@protonmail.com> writes:
>> The alternative is to make string data use safe by providing a mechanism
>> that does that. Emacs doesn't have such a mechanism yet. I proposed
>> a simple one using the binding stack.
>
> Sure, we can use the binding stack, but the easier way for most SDATA
> pointers is to scan the stack conservatively for valid SDATA pointers
> and use those to keep the respective sblocks pinned during the GC
> cycle.
Or that, even better!
[-- Attachment #2: Type: text/html, Size: 1670 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-05 20:20 ` Gerd Möllmann
2025-02-05 20:54 ` [Ext]Re: " Edward Reingold
@ 2025-02-06 0:12 ` Pip Cet via Emacs development discussions.
2025-02-06 7:47 ` Gerd Möllmann
2025-02-06 10:19 ` Eli Zaretskii
1 sibling, 2 replies; 76+ messages in thread
From: Pip Cet via Emacs development discussions. @ 2025-02-06 0:12 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>
>>> The alternative is to make string data use safe by providing a mechanism
>>> that does that. Emacs doesn't have such a mechanism yet. I proposed
>>> a simple one using the binding stack.
>>
>> Sure, we can use the binding stack, but the easier way for most SDATA
>> pointers is to scan the stack conservatively for valid SDATA pointers
>> and use those to keep the respective sblocks pinned during the GC
>> cycle.
>
> Or that, even better!
Long patch follows. It supposedly does two things:
1. If you put a Lisp_Object in SAFE_ALLOCA'd memory, and SAFE_ALLOCA
actually xmalloc'd it, that will work instead of crashing Emacs if you
end up calling GC.
2. If you keep an SDATA pointor on the stack when GC strikes, the SDATA
pointer will remain valid.
1|2. If you keep an SDATA pointer in SAFE_ALLOCA'd memory, you're also
safe.
Note that if you call Lisp, and Lisp modifies a string whose SDATA
pointer you currently have on the stack (or in SAFE_ALLOCA'd memory),
things might work or not.
I believe that installing this patch may speed up the merge of
feature/igc, by finally getting us out of the recurring thought pattern
that we most somehow avoid GC when doing somethin as innocuous as
iterating over a string.
While it would be natural to drop pin_string, and there were no
immediate problems when I tried that (well, I did have to make sure the
SDATA on the bytecode stack was marked), it's not clear what the
performance implications may be: bytecode strings are longer than
typiacl "short" Emacs strings, but too short to be malloc'd directly
because of their size, so they might end up being the dominating factor
for string compaction.
Again, to me the relevant criterion is whether this patch helps get
feature/igc merged; if it doesn't, it should be delayed until after the
merge.
Pip
From 5bb42376763334d6accff0b6e8c50dd674a1452b Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@protonmail.com>
Subject: [PATCH] Expand conservative stack scanning
Modify SDATA pointers on the stack to protect their SDATA objects.
Also scan memory obtained by the SAFE_ALLOCA family of functions
conservatively.
This removes the two major reasons for no-GC assumptions.
* src/alloc.c (enum mem_type): Add 'MEM_TYPE_STRING_DATA',
'MEM_TYPE_STRING_DATA_BLOCK', 'MEM_TYPE_SAFE_ALLOCA'.
(xzalloc_safe_alloca): Safe version of xzalloc.
(xfree): Add check.
(xnmalloc_safe_alloca): Safe version of 'xnmalloc'.
(record_xmalloc_safe_alloca): Safe version of 'record_xmalloc'.
(lisp_mem_mark): New function.
(allocate_string_data): Allocate as 'MEM_TYPE_STRING_DATA' or
'MEM_TYPE_STRING_DATA_BLOCK'. Initialize 'do_not_move' flag.
(free_large_strings): Obey 'do_not_move' flag; delay freeing such
strings until the next cycle..
(compact_small_strings): Build a new list of sblocks interleaving
potentially modified sblocks which were not pinned mith unmodified
sblocks which were marked as 'do_not_move'. Ultimately clear all
'do_not_move' flags.
(mark_maybe_pointer): Handle 'MEM_TYPE_STRING_DATA' and
'MEM_TYPE_STRING_DATA_BLOCK' by pinning the relevant sblocks. Ignore
'MEM_TYPE_SAFE_ALLOCA' as it's only needed for the specpdl.
* src/lisp.h (SAFE_ALLOCA):
(SAFE_NALLOCA):
(safe_free):
(SAFE_ALLOCA_LISP_EXTRA): Make safer by registering all memory to be
scanned.
---
src/alloc.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++-----
src/lisp.h | 21 +++++---
2 files changed, 147 insertions(+), 21 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index 7fa05e54202..f9cfdad3df0 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -405,6 +405,9 @@ no_sanitize_memcpy (void *dest, void const *src, size_t size)
MEM_TYPE_NON_LISP,
MEM_TYPE_CONS,
MEM_TYPE_STRING,
+ MEM_TYPE_STRING_DATA,
+ MEM_TYPE_STRING_DATA_BLOCK,
+ MEM_TYPE_SAFE_ALLOCA,
MEM_TYPE_SYMBOL,
MEM_TYPE_FLOAT,
/* Since all non-bool pseudovectors are small enough to be
@@ -417,6 +420,8 @@ no_sanitize_memcpy (void *dest, void const *src, size_t size)
MEM_TYPE_SPARE
};
+static void *lisp_malloc (size_t nbytes, bool clearit, enum mem_type type);
+
static bool
deadp (Lisp_Object x)
{
@@ -706,6 +711,24 @@ xzalloc (size_t size)
return val;
}
+/* Like the above, but ensures the memory will be scanned conservatively. */
+
+void *
+xzalloc_safe_alloca (size_t size)
+{
+ void *val;
+
+ MALLOC_BLOCK_INPUT;
+ val = lisp_malloc (size + 1, true, MEM_TYPE_SAFE_ALLOCA);
+ ((char *)val)[size] = 0;
+ MALLOC_UNBLOCK_INPUT;
+
+ if (!val)
+ memory_full (size);
+ MALLOC_PROBE (size);
+ return val;
+}
+
/* Like realloc but check for no memory and block interrupt input. */
void *
@@ -734,6 +757,10 @@ xfree (void *block)
if (pdumper_object_p (block))
return;
MALLOC_BLOCK_INPUT;
+#ifdef ENABLE_CHECKING
+ if (mem_find (block) != MEM_NIL)
+ emacs_abort ();
+#endif
free (block);
MALLOC_UNBLOCK_INPUT;
/* We don't call refill_memory_reserve here
@@ -761,6 +788,20 @@ xnmalloc (ptrdiff_t nitems, ptrdiff_t item_size)
}
+/* Like the above, but ensure the memory will be scanned for
+ references. */
+
+void *
+xnmalloc_safe_alloca (ptrdiff_t nitems, ptrdiff_t item_size)
+{
+ eassert (0 <= nitems && 0 < item_size);
+ ptrdiff_t nbytes;
+ if (ckd_mul (&nbytes, nitems, item_size) || SIZE_MAX < nbytes)
+ memory_full (SIZE_MAX);
+ return xzalloc_safe_alloca (nbytes);
+}
+
+
/* Reallocate an array PA to make it of NITEMS items, each of size ITEM_SIZE.
Signal an error on memory exhaustion, and block interrupt input. */
@@ -899,6 +940,17 @@ record_xmalloc (size_t size)
}
+/* Return a newly allocated memory block of SIZE bytes, remembering
+ to free it when unwinding. */
+void *
+record_xmalloc_safe_alloca (size_t size)
+{
+ void *p = lisp_malloc (size, true, MEM_TYPE_SAFE_ALLOCA);
+ record_unwind_protect_ptr_mark (lisp_free, p, lisp_mem_mark);
+ return p;
+}
+
+
#if ! USE_LSB_TAG
extern void *lisp_malloc_loser;
void *lisp_malloc_loser EXTERNALLY_VISIBLE;
@@ -962,7 +1014,7 @@ lisp_malloc (size_t nbytes, bool clearit, enum mem_type type)
/* Free BLOCK. This must be called to free memory allocated with a
call to lisp_malloc. */
-static void
+void
lisp_free (void *block)
{
if (pdumper_object_p (block))
@@ -979,6 +1031,17 @@ lisp_free (void *block)
MALLOC_UNBLOCK_INPUT;
}
+void
+lisp_mem_mark (void *block)
+{
+ if (pdumper_object_p (block))
+ return;
+
+ struct mem_node *m = mem_find (block);
+ eassert (m != MEM_NIL);
+ mark_memory (m->start, m->end);
+}
+
/***** Allocation of aligned blocks of memory to store Lisp data. *****/
/* The entry point is lisp_align_malloc which returns blocks of at most
@@ -1475,6 +1538,8 @@ #define SDATA_DATA(S) ((struct sdata *) (S))->data
of the sblock if there isn't any space left in this block. */
sdata *next_free;
+ bool do_not_move;
+
/* String data. */
sdata data[FLEXIBLE_ARRAY_MEMBER];
};
@@ -1810,7 +1875,8 @@ allocate_string_data (struct Lisp_String *s,
MALLOC_BLOCK_INPUT;
- if (nbytes > LARGE_STRING_BYTES || immovable)
+#define PIP_IS_LAZY 0
+ if (nbytes > LARGE_STRING_BYTES || immovable || PIP_IS_LAZY)
{
size_t size = FLEXSIZEOF (struct sblock, data, needed);
@@ -1819,7 +1885,7 @@ allocate_string_data (struct Lisp_String *s,
mallopt (M_MMAP_MAX, 0);
#endif
- b = lisp_malloc (size + GC_STRING_EXTRA, clearit, MEM_TYPE_NON_LISP);
+ b = lisp_malloc (size + GC_STRING_EXTRA, clearit, MEM_TYPE_STRING_DATA);
ASAN_POISON_SBLOCK_DATA (b, size);
#ifdef DOUG_LEA_MALLOC
@@ -1830,6 +1896,7 @@ allocate_string_data (struct Lisp_String *s,
data = b->data;
b->next = large_sblocks;
b->next_free = data;
+ b->do_not_move = false;
large_sblocks = b;
}
else
@@ -1841,12 +1908,13 @@ allocate_string_data (struct Lisp_String *s,
< (char *) b->next_free - (char *) b + needed))
{
/* Not enough room in the current sblock. */
- b = lisp_malloc (SBLOCK_SIZE, false, MEM_TYPE_NON_LISP);
+ b = lisp_malloc (SBLOCK_SIZE, false, MEM_TYPE_STRING_DATA_BLOCK);
ASAN_POISON_SBLOCK_DATA (b, SBLOCK_SIZE);
data = b->data;
b->next = NULL;
b->next_free = data;
+ b->do_not_move = false;
if (current_sblock)
current_sblock->next = b;
@@ -2060,14 +2128,20 @@ free_large_strings (void)
for (b = large_sblocks; b; b = next)
{
next = b->next;
+ if (b->do_not_move)
+ {
+ b->do_not_move = false;
+ continue;
+ }
- if (b->data[0].string == NULL)
- lisp_free (b);
- else
+ struct Lisp_String *s = b->data[0].string;
+ if (!s)
{
- b->next = live_blocks;
- live_blocks = b;
+ lisp_free (b);
+ continue;
}
+ b->next = live_blocks;
+ live_blocks = b;
}
large_sblocks = live_blocks;
@@ -2083,6 +2157,15 @@ compact_small_strings (void)
/* TB is the sblock we copy to, TO is the sdata within TB we copy
to, and TB_END is the end of TB. */
struct sblock *tb = oldest_sblock;
+ struct sblock **prev_tb = &oldest_sblock;
+ struct sblock **prev_fb = NULL;
+
+ while (tb && tb->do_not_move)
+ {
+ prev_tb = &tb->next;
+ tb = tb->next;
+ }
+
if (tb)
{
sdata *tb_end = (sdata *) ((char *) tb + SBLOCK_SIZE);
@@ -2097,7 +2180,17 @@ compact_small_strings (void)
sdata *end = b->next_free;
eassert ((char *) end <= (char *) b + SBLOCK_SIZE);
- for (sdata *from = b->data; from < end; )
+ if (b->do_not_move)
+ {
+ struct sblock *next = b->next;
+ b->next = *prev_tb;
+ *prev_tb = b;
+ prev_tb = &b->next;
+ b = next;
+ *prev_fb = next;
+ continue;
+ }
+ else for (sdata *from = b->data; from < end; )
{
/* Compute the next FROM here because copying below may
overwrite data we need to compute it. */
@@ -2134,7 +2227,13 @@ compact_small_strings (void)
if (to_end > tb_end)
{
tb->next_free = to;
- tb = tb->next;
+ do
+ {
+ tb->do_not_move = false;
+ prev_tb = &tb->next;
+ tb = *prev_tb;
+ }
+ while (tb->do_not_move);
tb_end = (sdata *) ((char *) tb + SBLOCK_SIZE);
to = tb->data;
to_end = (sdata *) ((char *) to + size + GC_STRING_EXTRA);
@@ -2154,7 +2253,8 @@ compact_small_strings (void)
}
from = from_end;
}
- b = b->next;
+ prev_fb = &b->next;
+ b = *prev_fb;
}
while (b);
@@ -2167,8 +2267,16 @@ compact_small_strings (void)
b = next;
}
- tb->next_free = to;
tb->next = NULL;
+
+ for (b = oldest_sblock; b; )
+ {
+ struct sblock *next = b->next;
+ b->do_not_move = false;
+ b = next;
+ }
+
+ tb->next_free = to;
}
current_sblock = tb;
@@ -4299,7 +4407,7 @@ refill_memory_reserve (void)
spare_memory[0] = malloc (SPARE_MEMORY);
if (spare_memory[1] == 0)
spare_memory[1] = lisp_align_malloc (sizeof (struct cons_block),
- MEM_TYPE_SPARE);
+ MEM_TYPE_SPARE);
if (spare_memory[2] == 0)
spare_memory[2] = lisp_align_malloc (sizeof (struct cons_block),
MEM_TYPE_SPARE);
@@ -5049,6 +5157,14 @@ mark_maybe_pointer (void *p, bool symbol_only)
/* Nothing to do; not a pointer to Lisp memory. */
return;
+ case MEM_TYPE_STRING_DATA_BLOCK:
+ case MEM_TYPE_STRING_DATA:
+ {
+ struct sblock *sblock = m->start;
+ sblock->do_not_move = true;
+ return;
+ }
+
case MEM_TYPE_CONS:
{
if (symbol_only)
@@ -5113,6 +5229,9 @@ mark_maybe_pointer (void *p, bool symbol_only)
}
break;
+ case MEM_TYPE_SAFE_ALLOCA:
+ return;
+
default:
emacs_abort ();
}
diff --git a/src/lisp.h b/src/lisp.h
index 6aea51f8322..f25b89c15e4 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -5527,11 +5527,17 @@ NATIVE_COMP_FUNCTION_DYNP (Lisp_Object a)
ATTRIBUTE_MALLOC_SIZE ((1)) ATTRIBUTE_RETURNS_NONNULL;
extern void *xzalloc (size_t)
ATTRIBUTE_MALLOC_SIZE ((1)) ATTRIBUTE_RETURNS_NONNULL;
+extern void *xzalloc_safe_alloca (size_t)
+ ATTRIBUTE_MALLOC_SIZE ((1)) ATTRIBUTE_RETURNS_NONNULL;
extern void *xrealloc (void *, size_t)
ATTRIBUTE_ALLOC_SIZE ((2)) ATTRIBUTE_RETURNS_NONNULL;
extern void xfree (void *);
+extern void lisp_free (void *);
+extern void lisp_mem_mark (void *);
extern void *xnmalloc (ptrdiff_t, ptrdiff_t)
ATTRIBUTE_MALLOC_SIZE ((1,2)) ATTRIBUTE_RETURNS_NONNULL;
+extern void *xnmalloc_safe_alloca (ptrdiff_t, ptrdiff_t)
+ ATTRIBUTE_MALLOC_SIZE ((1,2)) ATTRIBUTE_RETURNS_NONNULL;
extern void *xnrealloc (void *, ptrdiff_t, ptrdiff_t)
ATTRIBUTE_ALLOC_SIZE ((2,3)) ATTRIBUTE_RETURNS_NONNULL;
extern void *xpalloc (void *, ptrdiff_t *, ptrdiff_t, ptrdiff_t, ptrdiff_t)
@@ -5592,6 +5598,8 @@ #define eabs(x) ((x) < 0 ? -(x) : (x))
extern void *record_xmalloc (size_t)
ATTRIBUTE_ALLOC_SIZE ((1)) ATTRIBUTE_RETURNS_NONNULL;
+extern void *record_xmalloc_safe_alloca (size_t)
+ ATTRIBUTE_ALLOC_SIZE ((1)) ATTRIBUTE_RETURNS_NONNULL;
#define USE_SAFE_ALLOCA \
ptrdiff_t sa_avail = MAX_ALLOCA; \
@@ -5603,7 +5611,7 @@ #define AVAIL_ALLOCA(size) (sa_avail -= (size), alloca (size))
#define SAFE_ALLOCA(size) ((size) <= sa_avail \
? AVAIL_ALLOCA (size) \
- : record_xmalloc (size))
+ : record_xmalloc_safe_alloca (size))
/* SAFE_NALLOCA sets BUF to a newly allocated array of MULTIPLIER *
NITEMS items, each of the same type as *BUF. MULTIPLIER must
@@ -5615,8 +5623,8 @@ #define SAFE_NALLOCA(buf, multiplier, nitems) \
(buf) = AVAIL_ALLOCA (sizeof *(buf) * (multiplier) * (nitems)); \
else \
{ \
- (buf) = xnmalloc (nitems, sizeof *(buf) * (multiplier)); \
- record_unwind_protect_ptr (xfree, buf); \
+ (buf) = xnmalloc_safe_alloca (nitems, sizeof *(buf) * (multiplier)); \
+ record_unwind_protect_ptr_mark (lisp_free, buf, lisp_mem_mark); \
} \
} while (false)
@@ -5640,13 +5648,12 @@ safe_free (specpdl_ref sa_count)
specpdl_ptr--;
if (specpdl_ptr->kind == SPECPDL_UNWIND_PTR)
{
- eassert (specpdl_ptr->unwind_ptr.func == xfree);
- xfree (specpdl_ptr->unwind_ptr.arg);
+ specpdl_ptr->unwind_ptr.func (specpdl_ptr->unwind_ptr.arg);
}
else
{
eassert (specpdl_ptr->kind == SPECPDL_UNWIND_ARRAY);
- xfree (specpdl_ptr->unwind_array.array);
+ lisp_free (specpdl_ptr->unwind_array.array);
}
}
}
@@ -5692,7 +5699,7 @@ #define SAFE_ALLOCA_LISP_EXTRA(buf, nelt, extra) \
/* Although only the first nelt words need clearing, \
typically EXTRA is 0 or small so just use xzalloc; \
this is simpler and often faster. */ \
- (buf) = xzalloc (alloca_nbytes); \
+ (buf) = xzalloc_safe_alloca (alloca_nbytes); \
record_unwind_protect_array (buf, nelt); \
} \
} while (false)
--
2.48.1
^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-06 0:12 ` Pip Cet via Emacs development discussions.
@ 2025-02-06 7:47 ` Gerd Möllmann
2025-02-06 10:19 ` Eli Zaretskii
1 sibling, 0 replies; 76+ messages in thread
From: Gerd Möllmann @ 2025-02-06 7:47 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, emacs-devel
Pip Cet <pipcet@protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>>> The alternative is to make string data use safe by providing a mechanism
>>>> that does that. Emacs doesn't have such a mechanism yet. I proposed
>>>> a simple one using the binding stack.
>>>
>>> Sure, we can use the binding stack, but the easier way for most SDATA
>>> pointers is to scan the stack conservatively for valid SDATA pointers
>>> and use those to keep the respective sblocks pinned during the GC
>>> cycle.
>>
>> Or that, even better!
>
> Long patch follows. It supposedly does two things:
>
> 1. If you put a Lisp_Object in SAFE_ALLOCA'd memory, and SAFE_ALLOCA
> actually xmalloc'd it, that will work instead of crashing Emacs if you
> end up calling GC.
> 2. If you keep an SDATA pointor on the stack when GC strikes, the SDATA
> pointer will remain valid.
> 1|2. If you keep an SDATA pointer in SAFE_ALLOCA'd memory, you're also
> safe.
Thanks!
LGTM, and I like it a lot. Great improvement!
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-05 20:54 ` [Ext]Re: " Edward Reingold
@ 2025-02-06 8:01 ` Eli Zaretskii
0 siblings, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-06 8:01 UTC (permalink / raw)
To: Edward Reingold; +Cc: emacs-devel
> From: Edward Reingold <reingold@iit.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Wed, 5 Feb 2025 20:54:51 +0000
>
> How do I unsubscribe from this?
Sorry, you want unsubscribe from what? from the emacs-devel list? If
so, go to
https://lists.gnu.org/mailman/listinfo/emacs-devel
and follow the instructions for unsubscribing at the bottom of that
page.
If you meant something else, please tell.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Not protecting Lisp objects from GC
2025-02-06 0:12 ` Pip Cet via Emacs development discussions.
2025-02-06 7:47 ` Gerd Möllmann
@ 2025-02-06 10:19 ` Eli Zaretskii
1 sibling, 0 replies; 76+ messages in thread
From: Eli Zaretskii @ 2025-02-06 10:19 UTC (permalink / raw)
To: Pip Cet; +Cc: gerd.moellmann, emacs-devel
> Date: Thu, 06 Feb 2025 00:12:52 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>
> Long patch follows. It supposedly does two things:
>
> 1. If you put a Lisp_Object in SAFE_ALLOCA'd memory, and SAFE_ALLOCA
> actually xmalloc'd it, that will work instead of crashing Emacs if you
> end up calling GC.
> 2. If you keep an SDATA pointor on the stack when GC strikes, the SDATA
> pointer will remain valid.
> 1|2. If you keep an SDATA pointer in SAFE_ALLOCA'd memory, you're also
> safe.
Thanks, but please add extensive commentary that describes the design
of this and how it works. Ideally, we should also discuss the design
and its various aspects and consequences before this is installed. I
think we will also benefit from some description of how this should be
used and in what circumstances.
> Note that if you call Lisp, and Lisp modifies a string whose SDATA
> pointer you currently have on the stack (or in SAFE_ALLOCA'd memory),
> things might work or not.
This kind of code, which keeps an SDATA pointer around while we call
Lisp, was always a no-no. The only problem with that is that given
today's proliferation of calls to Lisp from C, almost every function
call could potentially lead to call into Lisp, so adding calls to
functions could invalidate code which was previously perfectly okay.
> While it would be natural to drop pin_string, and there were no
> immediate problems when I tried that (well, I did have to make sure the
> SDATA on the bytecode stack was marked), it's not clear what the
> performance implications may be: bytecode strings are longer than
> typiacl "short" Emacs strings, but too short to be malloc'd directly
> because of their size, so they might end up being the dominating factor
> for string compaction.
Can we get an idea of the performance implications by timing byte
compilation of the entire tree? Or by using other pertinent
benchmarks?
> Again, to me the relevant criterion is whether this patch helps get
> feature/igc merged; if it doesn't, it should be delayed until after the
> merge.
Why would it not help? Come to think about it, why would it at all
affect the merging (unless it will introduce bugs that will
destabilize the branch so much we will be afraid to land it)? I'm
probably missing something.
^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2025-02-06 10:19 UTC | newest]
Thread overview: 76+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-27 9:08 Not protecting Lisp objects from GC Gerd Möllmann
2025-01-27 9:46 ` Stefan Kangas
2025-01-27 13:11 ` Eli Zaretskii
2025-01-27 13:45 ` Gerd Möllmann
2025-01-27 13:01 ` Eli Zaretskii
2025-01-27 13:26 ` Gerd Möllmann
2025-01-27 14:00 ` Eli Zaretskii
2025-01-27 14:18 ` Gerd Möllmann
2025-01-27 15:10 ` Eli Zaretskii
2025-01-27 15:27 ` Gerd Möllmann
2025-01-27 15:55 ` Eli Zaretskii
2025-01-27 16:16 ` Gerd Möllmann
2025-01-27 16:35 ` Eli Zaretskii
2025-01-27 17:07 ` Gerd Möllmann
2025-01-27 18:58 ` tomas
2025-01-27 19:22 ` Gerd Möllmann
2025-01-27 19:51 ` Eli Zaretskii
2025-01-27 19:57 ` Gerd Möllmann
2025-01-27 20:00 ` Eli Zaretskii
2025-01-27 20:04 ` Gerd Möllmann
2025-01-27 20:17 ` Eli Zaretskii
2025-01-27 20:29 ` Gerd Möllmann
2025-01-28 5:15 ` tomas
2025-01-28 5:55 ` Gerd Möllmann
2025-01-28 7:26 ` tomas
2025-01-28 5:13 ` tomas
2025-01-28 12:46 ` Eli Zaretskii
2025-01-28 12:50 ` tomas
2025-01-28 22:24 ` Jeremy Bryant
2025-01-29 4:44 ` Gerd Möllmann
2025-01-29 23:09 ` Jeremy Bryant
2025-01-30 5:11 ` Gerd Möllmann
2025-01-30 7:52 ` Eli Zaretskii
2025-01-31 22:48 ` igc testing and bug reports -was- " Jeremy Bryant
2025-02-01 8:26 ` Eli Zaretskii
2025-02-01 8:53 ` Gerd Möllmann
2025-02-01 9:14 ` Pip Cet via Emacs development discussions.
2025-01-27 17:46 ` Stefan Kangas
2025-01-27 19:40 ` Eli Zaretskii
2025-01-27 22:18 ` Pip Cet via Emacs development discussions.
2025-01-28 12:27 ` Eli Zaretskii
2025-01-28 20:06 ` Pip Cet via Emacs development discussions.
2025-01-28 21:31 ` Stefan Kangas
2025-01-29 9:46 ` Pip Cet via Emacs development discussions.
2025-01-29 13:44 ` Eli Zaretskii
2025-01-29 17:51 ` Pip Cet via Emacs development discussions.
2025-01-29 19:11 ` Eli Zaretskii
2025-01-30 10:41 ` Pip Cet via Emacs development discussions.
2025-01-30 10:59 ` Eli Zaretskii
2025-01-30 11:52 ` Pip Cet via Emacs development discussions.
2025-01-30 12:35 ` Eli Zaretskii
2025-02-01 14:21 ` Pip Cet via Emacs development discussions.
2025-02-01 14:46 ` Eli Zaretskii
2025-02-01 15:06 ` Pip Cet via Emacs development discussions.
2025-02-01 15:34 ` Eli Zaretskii
2025-02-03 19:24 ` Pip Cet via Emacs development discussions.
2025-02-03 20:14 ` Eli Zaretskii
2025-02-03 21:07 ` Pip Cet via Emacs development discussions.
2025-02-04 4:17 ` Gerd Möllmann
2025-02-04 5:22 ` Gerd Möllmann
2025-02-04 16:22 ` Eli Zaretskii
2025-02-04 16:31 ` Eli Zaretskii
2025-02-04 18:17 ` Pip Cet via Emacs development discussions.
2025-02-04 19:55 ` Eli Zaretskii
2025-02-04 21:14 ` Gerd Möllmann
2025-02-04 21:08 ` Gerd Möllmann
2025-02-05 12:20 ` Eli Zaretskii
2025-02-05 13:38 ` Gerd Möllmann
2025-02-05 14:35 ` Eli Zaretskii
2025-02-05 17:09 ` Pip Cet via Emacs development discussions.
2025-02-05 20:20 ` Gerd Möllmann
2025-02-05 20:54 ` [Ext]Re: " Edward Reingold
2025-02-06 8:01 ` Eli Zaretskii
2025-02-06 0:12 ` Pip Cet via Emacs development discussions.
2025-02-06 7:47 ` Gerd Möllmann
2025-02-06 10:19 ` Eli Zaretskii
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.