GNU bug report logs - #65491
[PATCH] Improve performance allocating vectors

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 65491 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#65491: [PATCH] Improve performance allocating vectors
Date: Sat, 16 Sep 2023 12:46:34 -0700

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

Previous Next

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