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 18:49:56 +0100 Message-ID: References: <87jzbbke6u.fsf@protonmail.com> <86sepx8sth.fsf@gnu.org> <86h66d8pnl.fsf@gnu.org> <86ed1h8nji.fsf@gnu.org> <86o70l6ucl.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="29814"; 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 18:51:23 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 1tUUmZ-0007b3-7R for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 18:51:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUUmG-0007H7-M2; Sun, 05 Jan 2025 12:51:04 -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 1tUUmE-0007Gw-Pr for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 12:51: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 1tUUmE-000587-9s for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 12:51: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=o2onSEU6cZW+pDoTYz+Kz6SKlWUKE5dD2kgcJyrgYEA=; b=oIdrlP+Zcjo2j+B3OGDyty2CBxab8jIxeO08a42zkJF9q0xa5a2zaCwtX79G6TEqHPTcoc7FdXNYQpSa+C+feLks39PVeHkyeCUablo+UCulqBY6gkDOAI3Nx9ht6xfAJa/V4lxzvA6wJTivwXbmHDygWPv/8C+k7/95vL6X0WVCJoNLRt1vrOXJnPHCYFIIU8X5hSULbkLnO5Rjz8Zgid8YocW7mUm3/wGbI3uraqv+GD5l6TyMr0IBBqBDS0edaFqCzkJSJStdE8Pj7VQ0fuoSTWhhZmcLAbYP8Y3vF6BJqi7ps9wc5JKXCMn2WczwzIkUn9GUOrxJmomZ0L2pBQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUUmE-0008Aj-4O for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 12:51: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 17:51: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.173609940831165 (code B ref 75322); Sun, 05 Jan 2025 17:51:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 17:50:08 +0000 Original-Received: from localhost ([127.0.0.1]:35059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUUlL-00086N-CI for submit@debbugs.gnu.org; Sun, 05 Jan 2025 12:50:07 -0500 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:50586) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUUlI-00082m-UL for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 12:50:06 -0500 Original-Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-386329da1d9so6274835f8f.1 for <75322@debbugs.gnu.org>; Sun, 05 Jan 2025 09:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736099398; x=1736704198; 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=o2onSEU6cZW+pDoTYz+Kz6SKlWUKE5dD2kgcJyrgYEA=; b=HXP86kXw0GtErQsHu13nzKytKfByXMgrSgeMGyn5FTJxw4mZcrPsjogjx/hoqy+Q5H +CHuKBHDfD0Kq2EHtnTZyuF9Qb77wI/afb0yk/txFd3AvDvQtouyRPPynhxpCuBzRmAE s83gcX9nl1ppsOTko9q+9dWLJgKW5RiFjmWM/qS19qpKjaB83guj0mBUwxuK053xJm1y 8kigkKD3QGNgTs2Kx6p0tOaHGuQGXBrS8UlGjqcR7BfRp4WPYkoh4zxckGgbSqeB6jty IsUzmNfh5ZuN0mx/dLYxX1TiaaWn9TXhR64LUsiAbn0eaL/kpBgnvs8vIZyphQwa7D27 ql+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736099398; x=1736704198; 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=o2onSEU6cZW+pDoTYz+Kz6SKlWUKE5dD2kgcJyrgYEA=; b=L6n21QynNj995fRTqlzu5rkG677GqerdrJu5C1qxXxCPMGEU88FP7EXlIwpoev2J+J +BGgS6xeq6NasN9Bn3ixAV/j5dHc74ZeQYT2YpUGaw/lhV6kJ3kxqbWdhXv9Hd7t8tLF z5TKWVpT/PrpAXUtksk8frWHDjL/CAXdT4CowHELrivzMXjhz8DIVjgIBtvb/JofIWJp NW4xcxOkP5jirJ0sCFZ+8SKFv8Ks7FzkG+eo1x4nzqWmudTIYnGNJ4foWwnDgmMgQvEN ti5qRP6dIFSBASDP5kg2YtjJ8Lxr+CBH/uRO961Tw5nm+8CXlA/82PRCrdXXmp+NfWY+ P9xw== X-Forwarded-Encrypted: i=1; AJvYcCX4hmKnyTVy6ukOVrC1+V8b5uMALGSlOT9vCHrPDvBVRrfvOVETgIXrfOq/UBW1wJzymhzaAA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwOM2enkswmQbHLg/Z3ylnkOXFVn/M2cmYl2Uss/+tPToJCp1Aw rZqQFbqCnuezHrsjibYpOBUwT/P35sETTO97JLkfjWIjKrvwRTssWu/Xgw== X-Gm-Gg: ASbGncsYhT/YQJjkfZZPX2etH6uzcajg7wdlOxBc0jB5KSZVQypR9CbgJoKs3cPTV8D IfGg/9IVNKrtlBwgGXE5p31ZJD+0GqLJGxFmL6jCoskZ8btb5N4xj8NcZdDWsjm/yMgjL2xRE6m FEtH1IiKSEmMz7XUEbTtzFpeEZ+7Xk8Yz4SegKQBCPvnkedlkCaNCe36aYhGMvFaaxRXbxctY6c P0HFlVminvkRiR1ASmCHjalPbYZI8E3wXa+53TyHLd2iLw+3RXPiPTzK94JbP4xkYTDcMj1hQGg UpMN7W4QaXvsEdaKBR0abAOfA3AH1xprDGD5FyFTMHdkS8N3ICYK0/DNoc5LD8G2AA== X-Google-Smtp-Source: AGHT+IHsA6SC4rU/FjEAi14eeNdCvYYq8wSxmI/sR1OVUXKQXJwUU2kA/Pk6JTzLlG1yC0bxMZNzPg== X-Received: by 2002:adf:a591:0:b0:38a:4184:2510 with SMTP id ffacd0b85a97d-38a4184257bmr21513923f8f.23.1736099397712; Sun, 05 Jan 2025 09:49:57 -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-43661219a08sm549685205e9.25.2025.01.05.09.49.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 09:49:57 -0800 (PST) In-Reply-To: <86o70l6ucl.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2025 19:31:06 +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:298579 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org >> Date: Sun, 05 Jan 2025 14:21:04 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> > So can we talk about the relative merits and demerits of using >> > SAFE_ALLOCA_LISP vs SAFE_NALLOCA?=20=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. > > This surprises me because on the master branch SAFE_ALLOCA_LISP either > calls alloca or xzalloc. So I don't see why SAFE_ALLOCA_LISP would be > safer in the old GC than SAFE_NALLOCA. It's only on the igc branch > that you made SAFE_ALLOCA_LISP make a Lisp vector. > But this is a tangent from my POV. I would like to discuss the new > GC, not the old one. > This in SAFE_ALLOCA_LISP_EXTRA (buf) =3D xzalloc (alloca_nbytes); \ record_unwind_protect_array (buf, nelt); \ makes a specpdl entry, which makes mark_specpdl do this: case SPECPDL_UNWIND_ARRAY: mark_objects (pdl->unwind_array.array, pdl->unwind_array.nelts); break; >> > 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? >>=20 >> 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. > > But I presume that if we have more Lisp objects, GC will happen > sooner, no? So increasing GC pressure is not zero-cost, because more > frequent GC means more CPU processing that stops our application > thread. I don't know what exact consequences that has. MPS is at least an incremental collector, so it's not normally the case that the GC _starts_ at some given point. What certainly happens is that the array is allocated from an allocation point which has a certain amount of memory pre-allocated. And that pre-allocated memory will run out sooner, in which case the allocation point will acquire additional memory, which potentially requires some amount of GC. And so on. So it will have some effect, for sure, but I don't remember the docs spelling out details. Maybe someone else knows. > >> SAFE_NALLOCA, with my patch, requires a xmalloc, creation of a MPS root >> object, deletion of that, and xfree. >>=20 >> Let's assume scanning costs are more or less the same because the >> number of references is the same in both cases. > > But more memory allocated via xmalloc doesn't increase the frequency > of GC, does it? Xmalloc no, but as I said above...=20