From: Paul Eggert <eggert@cs.ucla.edu>
To: "Eli Zaretskii" <eliz@gnu.org>,
"Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: 65491@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#65491: [PATCH] Improve performance allocating vectors
Date: Sat, 16 Sep 2023 12:46:34 -0700 [thread overview]
Message-ID: <8af6fa1c-4873-bd6e-e896-ab5bb8d012a2@cs.ucla.edu> (raw)
In-Reply-To: <83r0mygi4y.fsf@gnu.org>
On 2023-09-16 10:09, Eli Zaretskii wrote:
> I also added Paul to the discussion, since he wrote most of the
> involved macros.
Mattias and I had a private email discussion about XUNTAG last month,
and he's correct that Emacs's current code, which #defines XUNTAG(a,
type, ctype) to ((ctype *) ((char *) XLP (a) - LISP_WORD_TAG (type))),
violates the C standard due to calculating a pointer outside its
containing object's bounds, whereas the patch P that you just reverted,
which defines the same macro to ((ctype *) ((uintptr_t) XLP (a) -
(uintptr_t) LISP_WORD_TAG (type))), does not have that particular
undefined behavior.
My own impression is that patch P is a net win, as it should make Emacs
more reliable after likely future changes, for two reasons.
First, the unpatched version's undefined behavior caused Emacs to crash
when Mattias tried out what appeared to be an obvious change to the GC's
vector handling. Had patch P been present, Emacs would not have crashed.
Second, I vaguely suspect any attempt by Emacs to exploit recent memory
safety improvements in Arm, Intel, etc. on GNU/Linux are more likely to
work with patch P than without it. I suspect this because most other
apps that tag pointers do it in the integer world (as patch P does), not
in the pointer world (as Emacs currently does). The developments I have
in mind are Arm MTE[1], Intel LAM[2], and (more speculatively)
CHERI-RISC-V[3]. Although this is just a suspicion, I suspect I've
thought about the issue more than anyone else has.
I would not favor a two-pronged approach, in which patch P is present
but is used optionally. This would likely cause more trouble than it'd
cure, due to lack of testing of the extra combinations. Let's use just
one approach and keep it simple and more testable.
[1]: https://lwn.net/Articles/834289/
[2]: https://lwn.net/Articles/902094/
[3]:
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-risc-v.html
next prev parent reply other threads:[~2023-09-16 19:46 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 9:59 bug#65491: [PATCH] Improve performance allocating vectors Ihor Radchenko
2023-08-26 7:14 ` Eli Zaretskii
2023-08-26 7:27 ` Ihor Radchenko
2023-08-26 7:31 ` Eli Zaretskii
2023-08-26 7:51 ` Ihor Radchenko
2023-08-26 8:07 ` Ihor Radchenko
2023-08-26 9:01 ` Eli Zaretskii
2023-08-26 7:47 ` Ihor Radchenko
2023-08-26 12:01 ` Mattias Engdegård
2023-08-26 14:54 ` Ihor Radchenko
2023-08-26 14:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-27 9:54 ` Mattias Engdegård
2023-09-16 14:58 ` Mattias Engdegård
2023-09-16 16:12 ` Eli Zaretskii
2023-09-16 16:17 ` Eli Zaretskii
2023-09-16 16:32 ` Mattias Engdegård
2023-09-16 16:54 ` Eli Zaretskii
2023-09-16 17:03 ` Mattias Engdegård
2023-09-16 17:11 ` Eli Zaretskii
2023-09-17 3:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-17 17:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 2:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 2:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 3:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 4:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-16 16:54 ` Mattias Engdegård
2023-09-16 17:09 ` Eli Zaretskii
2023-09-16 17:22 ` Mattias Engdegård
2023-09-16 18:19 ` Eli Zaretskii
2023-09-16 19:04 ` Mattias Engdegård
2023-09-16 19:46 ` Paul Eggert [this message]
2023-09-17 5:18 ` Eli Zaretskii
2023-09-17 15:22 ` Paul Eggert
2023-09-17 16:15 ` Eli Zaretskii
2023-09-17 16:37 ` Paul Eggert
2023-09-17 16:44 ` Eli Zaretskii
2023-09-18 16:10 ` Mattias Engdegård
2023-09-18 17:13 ` Eli Zaretskii
2023-09-19 13:28 ` Mattias Engdegård
2023-09-19 14:04 ` Eli Zaretskii
2023-09-19 14:05 ` Mattias Engdegård
2023-09-25 16:06 ` Mattias Engdegård
2023-08-27 16:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-28 10:14 ` Ihor Radchenko
2023-08-28 16:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-28 12:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8af6fa1c-4873-bd6e-e896-ab5bb8d012a2@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=65491@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=mattias.engdegard@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.