From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#65491: [PATCH] Improve performance allocating vectors Date: Sat, 16 Sep 2023 12:46:34 -0700 Organization: UCLA Computer Science Department Message-ID: <8af6fa1c-4873-bd6e-e896-ab5bb8d012a2@cs.ucla.edu> References: <6B2EDD07-AAEB-40E8-B369-F634296BD3D9@gmail.com> <83v8cagkqv.fsf@gnu.org> <83ttrugkj2.fsf@gnu.org> <83r0mygi4y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11827"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Cc: 65491@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 16 21:47:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qhbG5-0002o4-0q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Sep 2023 21:47:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhbFs-0002nP-4k; Sat, 16 Sep 2023 15:47:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhbFn-0002mr-Jg for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 15:46:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qhbFm-0004O8-Iv for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 15:46:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qhbFt-0000A4-Ip for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 15:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 19:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65491 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65491-submit@debbugs.gnu.org id=B65491.1694893616609 (code B ref 65491); Sat, 16 Sep 2023 19:47:01 +0000 Original-Received: (at 65491) by debbugs.gnu.org; 16 Sep 2023 19:46:56 +0000 Original-Received: from localhost ([127.0.0.1]:48565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhbFn-00009k-H3 for submit@debbugs.gnu.org; Sat, 16 Sep 2023 15:46:55 -0400 Original-Received: from mail.cs.ucla.edu ([131.179.128.66]:43394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhbFi-00009R-KL for 65491@debbugs.gnu.org; Sat, 16 Sep 2023 15:46:53 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C83253C00D189; Sat, 16 Sep 2023 12:46:37 -0700 (PDT) Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XqXnop6puLhO; Sat, 16 Sep 2023 12:46:36 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id F298C3C00D195; Sat, 16 Sep 2023 12:46:35 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu F298C3C00D195 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1694893596; bh=G4vG/kLPa2HCW9fSKGe21CxIoiI6W/rjh4rfs4wKPfM=; h=Message-ID:Date:MIME-Version:To:From; b=Loih5slQ80djcVNpL1sW82XHe08arLLEt8WFNkey+c4430hvNtJJ5QLN7T+IHXOG4 +mfDy2budhlLdTS2E2GTH7Z+EKZUCvK1e7wGxgTD3tzjB9ILknyU+QCmDLu2MvHaXN Uh9yFZXLeseoQSR9txwxSCfgsL92uBtW4MufTlp69KKnq56VKKsQMC1BADq2GzWH6T sx8+z89SSfkOSYgEYRE9O0bRR4Vx3Axm1cto46AhvLCs3ObJQWxLjleYZvpmIGG0vZ S0hz1S26gVS6/E/FxPhCAKXa5kbt8nmsmmD4MxsUyl6WBkVcSZpuu4nDnU3czWW00U 5tHbKL+i58NZg== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fVBPbOIWSL53; Sat, 16 Sep 2023 12:46:35 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id C5ABC3C00D194; Sat, 16 Sep 2023 12:46:35 -0700 (PDT) Content-Language: en-US In-Reply-To: <83r0mygi4y.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270646 Archived-At: 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