From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 14:21:04 +0100 Message-ID: References: <87jzbbke6u.fsf@protonmail.com> <86sepx8sth.fsf@gnu.org> <86h66d8pnl.fsf@gnu.org> <86ed1h8nji.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10187"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 14:22:12 2025 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 1tUQa3-0002Uh-W2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 14:22:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUQZx-0003cL-4V; Sun, 05 Jan 2025 08:22:05 -0500 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 1tUQZu-0003c4-R4 for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 08:22:02 -0500 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 1tUQZu-0003Ib-IG for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 08:22:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=bQNXoKgDv85+zoWmAs9nCWuxoqWJpOtF6vpCz8zt1P8=; b=dgnKzGzBwdur+MxQ9FO8v+jKJjLXK5e7offAK8wtHFRIFI+tJG271cFoyJjHIhPIvqq8Yz56JwrvTNqmAlPRO1AKb6KpvKXVawaExW+69I4kHLLq/WoxqeAneD151qh2nkCJ7d005o2WXZ4tHILByQWVbkiV3cNaU7gVlWmSYjy/QUNb1NTQyVJZB3Mbfueao8eWSVt2oJxO1OJnUwz3uYY6XVhypwWhuCpAk6SqNWLoQsUv7rz6iWiVJlz3rHipuLfHvXGfdewabZo22/3BKxcBZbsxXqL1gMzw/aCuwsRFqABJBJKafTbknqYk0ywovswsiNQMN9sqIOc8wGcEeQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUQZu-0002ir-8y for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 08:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 13:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.173608327510363 (code B ref 75322); Sun, 05 Jan 2025 13:22:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 13:21:15 +0000 Original-Received: from localhost ([127.0.0.1]:60367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUQZ9-0002h4-6r for submit@debbugs.gnu.org; Sun, 05 Jan 2025 08:21:15 -0500 Original-Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:42260) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUQZ7-0002gn-3i for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 08:21:13 -0500 Original-Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4361b6f9faeso81575225e9.1 for <75322@debbugs.gnu.org>; Sun, 05 Jan 2025 05:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736083266; x=1736688066; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bQNXoKgDv85+zoWmAs9nCWuxoqWJpOtF6vpCz8zt1P8=; b=VsWi+xy0h5QhMy5A6i/mdPNrox4pjiWK3/E3aFhuxDkwySIHpP88z3xsNZga/CTGoR WWk86f0StgVH+jvBLFa3p2gVZSkerk1KTs2b6+KmrBl4+f3XTKMAJ9t4Q9kpthA3anOX snsUglA1BmGNAMpc72GSTvYJ/M+oEY0XGiVAyfe7IMJVohdfeKoDHmQRObiCwLxVSdoK Y9PEtmRSIRYbLa8KuCGtnjNAsEUm3WSDuxHeDoYsmi7TFgNGB8qk7il2CNwrNSy6Qr2n 0zhYkDMoAoGoccaVoP/463VDrJcDEU0lZd2/UIWD0beSGuViig2o2y8AYOs8vTpINk9r 17KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736083266; x=1736688066; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bQNXoKgDv85+zoWmAs9nCWuxoqWJpOtF6vpCz8zt1P8=; b=fcUJXmLOS7wcF20icjdgtuFGYcAnoEtNAQzXFIk+1NTA0wbsdMVTqgNx/HrWoi5iMF NEOItpobcVNxTkP5xTsb3LcxLFF6UAouKJ1oPYi8S1XZbvbp2xmw1DKilnzSvE5Gzm6N BT/qJ772rx6tiba6IqovH7GYExuuvALQzQXqMO7nMDz5dM06YVJZ6TD1r0xU7tnByK/c u8YUb1BdnHhOsLwov3OLjR/t96UW13cNHAhmJ1okb3ecb4yLuR/6kHvCe3TVv6ZcFOyx me+wjoANtch493XazuDiHFllP+w7utDziEd8fHwBPsyWhTpS0SDTJVYDtx/h1IRXJyjG wtyg== X-Forwarded-Encrypted: i=1; AJvYcCXc2YDsrdWj7aP2h+y2z1SxrBx1M01Rcw+o81ZX2cKBDY7mLcjDvGYDBRgWd+i3WLespbUJhA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwpttG6ZQdlegfHiNJftgTE7WUzV1Ld6oCUDWhpEnpRJngGUxKJ Xm5269kSstZqb9ItUGD0bGpHXu9gThLyobBjfvltxcokytORF6fjUadUJw== X-Gm-Gg: ASbGnct1yxmd0SsbsH5LfB8RnwA/9SChuO5QFo6sayPqPp7S+py94AGAQAllZRFhnc0 +rLV56FCfNBJ/cdgkcSsTtcF95UOX4eykRgCkbFYT+o0MNao2vijd1uB/fIpLh2wpSqWjr9KCX5 0DQVYSi/1ON1rBOHdMknSkKC/KZGpeGD3WrgqJjS2ygFZsJrT5ftXi5kL7XKS4Ahlq+3P+vidij uznftzDyJtUqXqRgSowlgBfj9WrxTV+8KC7Zki+L7VjDNE8CqSqfqykeAPhK5+wg8zjb11NTt17 5vPsC2RHUpTrSfuNlkY70LBB2OOlkysJC+U0esnuWPO5JqiJh0MO2ZU+vTNnFNIn8g== X-Google-Smtp-Source: AGHT+IG9xQ9xny4THkfsiWrdJqO4YsfAr0zBNGTusXPkRGcqBGKZJI8qw59WpGz/J+hdYL876x72DQ== X-Received: by 2002:a05:600c:4f4f:b0:434:fc5d:179c with SMTP id 5b1f17b1804b1-43669a25fb4mr467186605e9.13.1736083266231; Sun, 05 Jan 2025 05:21:06 -0800 (PST) Original-Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43661219a08sm544271725e9.25.2025.01.05.05.21.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 05:21:05 -0800 (PST) In-Reply-To: <86ed1h8nji.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2025 14:15:13 +0200") 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:298561 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org >> Date: Sun, 05 Jan 2025 12:37:42 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> >> If you mean the two patches I sent with "these two", then no. I prefer >> >> using SAFE_ALLOCA_LISP because that introduces an exact root. >> > >> > I guess I'm confused, then. The first patch replaces calls to >> > SAFE_NALLOCA by SAFE_ALLOCA_LISP, the second patch modifies >> > SAFE_NALLOCA to call igc_xnmalloc_ambig. That's why I thought they >> > were alternatives. >> > >> > If they are not alternatives, then why did you replace SAFE_NALLOCA in >> > the first patch? >>=20 >> I checked other uses of SAFE_NALLOCA that were not yet mentioned, and >> found another problematic case. (Something with struct itree_node *, >> don't remember the function name, it's in some other mail). There were >> too many grep hits for SAFE_NALLOCA for me, so I shot with a canon :-). > > OK. > > So can we talk about the relative merits and demerits of using > SAFE_ALLOCA_LISP vs SAFE_NALLOCA?=20=20 Let me add a (0): I assume that SAFE_ALLOCA_LISP is the right thing in the _old_ GC, because it makes sure objects referenced in the xmalloc'd memory are marked. From my POV, it would require a very good reason to use something else, which is nowhere mentioned. That's why I suspect it's a left-over from times where SAFE_ALLOCA_LISP didn't exist. (And I very much hope it's not the old pattern of "I don't need to GCPRO this because I know this is already protected because of so-and-so", which you might still remember from the old times. In which cases I would've liked to hit people with a GCPRO on their head when I had to debug that and so-on-so was no longer true :-).) > First, why is it better to have an exact root than an ambiguous root? In the most general case, where an ambiguous root can contain random bit patterns, say the C stack, I'd say the greatest advantage of exact roots is avoiding false positives that keep objects alive, or prevent copying them. In the specific here case, where a root actually contains only Lisp_Objects, and not random patterns, I'd say the advantage of exact roots is that they don't prevent copying. The "prevent copying" disadvantage is a bit hand-wavy, and depends a lot on the GC implementation. Maybe a good picture of it that one would like to have a fully copying collector, with its advantage of reducing fragmentation, for example, but one can only have a mostly-copying collector, because of ambiguous references. The more the "mostly" is true the better for the copying/fragmentation. Does that make sense? > And second, SAFE_ALLOCA_LISP conses a Lisp vector, which will increase > GC pressure, so isn't SAFE_NALLOCA preferable at least in some cases? SAFE_ALLOCA_LISP allocates a Lisp vector, that's true. I think one can say that allocation is cheap on average. The overhead of freeing it is not copying it, which is basically zero. SAFE_NALLOCA, with my patch, requires a xmalloc, creation of a MPS root object, deletion of that, and xfree. Let's assume scanning costs are more or less the same because the number of references is the same in both cases. I think SAFE_NALLOCA is more expensive,