Eli Zaretskii <eliz@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Eli Zaretskii <eliz@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 78620) by debbugs.gnu.org; 30 May 2025 04:19:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 00:19:56 2025 Received: from localhost ([127.0.0.1]:42976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uKrDo-0007K7-6V for submit <at> debbugs.gnu.org; Fri, 30 May 2025 00:19:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47766) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uKrDl-0007JO-8G; Fri, 30 May 2025 00:19:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1uKrDe-0002U8-Vr; Fri, 30 May 2025 00:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=WrYtAZEYztpPtTOcYVpA2aAvK39WgKiz5UGMWg33grE=; b=Kao/iui8oB0WqVKUIDyV 2oI6vTsPm2JxlCCaEy9Mx9AcwlfYoITdCyFACqX+YcFYEdmaz3ADNER64U/L0/L3ew+HOQ8upgZLk adyW2u3DaqTqyMaajoLUhdQ11it95vCL+2UHsp7cP81o3baTBk6kRFZrjLwP0860d9GRW7eI98JBI 5RzYpcxruWRyEp17LBmdJ5RlEIjhZz2T7poeiLfVRMDQ6UcYflU6NSuCgpwiO4IxMQcUCHxG5HbQr pqKuvD4+g3QOjBzwl1rNlkpEJ7LehVlUvbNfftYdsiCQ0D34m3KHXqTVzH4ztPvRwqSAX9zhKOmoC jU1GlrrIMyJDqg==; Date: Fri, 30 May 2025 07:19:43 +0300 Message-Id: <864ix2vig0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Helmut Eller <eller.helmut@HIDDEN> In-Reply-To: <874ix3l6hj.fsf@HIDDEN> (message from Helmut Eller on Thu, 29 May 2025 18:35:52 +0200) Subject: Re: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector References: <E7CC8517-E7D3-4507-B9EF-3D396C451E86@HIDDEN> <874ix3l6hj.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78620 Cc: mattias.engdegard@HIDDEN, 78620 <at> debbugs.gnu.org, pipcet@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) tags 78620 notabug wontfix close 78620 thanks > Cc: Pip Cet <pipcet@HIDDEN>, 78620 <at> debbugs.gnu.org > From: Helmut Eller <eller.helmut@HIDDEN> > Date: Thu, 29 May 2025 18:35:52 +0200 > > On Thu, May 29 2025, Mattias Engdegård wrote: > > [...] > > This is the reason why it's written that way, and plenty of > > measurements were made at the time. There may still be good arguments > > for changing the structure but be careful, and don't do it for > > aesthetics alone. > > Okay, then I withdraw my proposal. I'm therefore closing this bug.
bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.Received: (at 78620) by debbugs.gnu.org; 29 May 2025 16:36:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 29 12:36:06 2025 Received: from localhost ([127.0.0.1]:38021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uKgEg-0005sE-FT for submit <at> debbugs.gnu.org; Thu, 29 May 2025 12:36:06 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:49465) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1uKgEb-0005ra-Le for 78620 <at> debbugs.gnu.org; Thu, 29 May 2025 12:36:03 -0400 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3a365a6804eso882588f8f.3 for <78620 <at> debbugs.gnu.org>; Thu, 29 May 2025 09:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748536554; x=1749141354; 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=sE101YWIf9s49I0dgz7FBvA1IiGSGixgLNo9nwjUGc0=; b=hqnPTTJqFrUKSbaQLW3rNoSLnBHXlIuaVhB4UnppGvROlg8xkt9G4dS6CDRAtwZTjo CFwBfy1WjkNmZxg2LyFfs+uingR/OUwgDAY7fLJAXDp3zoj0iqhw7DES/rA8FFhWPk3S RlhxgRP6wLJ1n/cQEvU8uojoraTbvK3efzKwkzc4TqsVzmpSKxHOHRg/NBri1ZPFcgaM Xty2VtVUiQf41dWLi21ycagMZEy4xYYdgQotm2muSvRshTNDbJ+8ZXnDgW1GzBYcSW3L mngjl7NOwv46LP+yF5wurR6cGowxuRsNFv8XpDkrUm/bh0Ug8vLempc/KPqPphcrua1o mlCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748536554; x=1749141354; 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=sE101YWIf9s49I0dgz7FBvA1IiGSGixgLNo9nwjUGc0=; b=e+FfGzP9NS10KHkzR+qCaHX+DmrNB+Ul+W8qC/3Z+ftuGpRlPuD6QiNjkHJb3AFZaj JF1mxz8oXKdSBFRpIJHmzUkU5uPBeHeW3UGoRPq4rTFgP7tBdk0Ap2akADLFwYYY6Pwj Pa1w4Cba5V/hPD4ajXq/25G95c4+mHKy5D5drgrjGi70yFLMcWyJMeugBmeM7PqGgERc G2GaIJ3Z6eHZU2vsY0rUbxxxj03uCGNg/5BIoNnu7POgPjjL2xBGAUsswCueXqvjzDIF zaUbUdwoaF3p6zFr215Tf+kKOfeDoTLYBZnDB6e70bHVP/JuxOcTzK8GgAnU0kDKTKl4 wYkg== X-Gm-Message-State: AOJu0YyJYWg0OuyC/0sMajadjwtLiP7lenxfF6v4mymZiiD9wqdQXnJO qciuTzoId1pGXkG9KLVNSQJpLgjJk1xyDpZ4c6HfhBa8Fay01lGExR6n X-Gm-Gg: ASbGnctzlmFI+mLa9+j8s7TdigN77yPI9UgWK9pxoZrGIAzUmNUM7DlH6u4NtoOVx0C Sksszqr0Lg54CFJMqHHEkOTTec3U+ImVGBXGtjzKcxj0aSw40xNAIpLo6pDYW7q7j0YTl+LPbFQ n6I56UelFt2bIp5jTRrQ6RiQk1V2RlacoJCjRB79PfnkNzf0ZGTUM960rKyeUZa7GMEta5Lbmc1 rNMzTh/6r63IfQJWpZ1p8AhvbpD0tuU2RgOUsMOXOtwbKfD+GgUlJxnxEoItfxVWSARcCNIQF/w d1QbW+CGv8mRSFCfrSUghXJoNvwfObKE2BJRvwu2Nv+9UOFf8ohyadYedAk= X-Google-Smtp-Source: AGHT+IG1adKvBnJauVoMw+yz4Far8HOc0aQ6RcgyhMgaHcibA0xk0AIK2/ZUVsWcdUStJNDezsJ1Fw== X-Received: by 2002:a05:6000:1885:b0:3a4:ef99:5ace with SMTP id ffacd0b85a97d-3a4f35b692emr2264437f8f.15.1748536553968; Thu, 29 May 2025 09:35:53 -0700 (PDT) Received: from caladan ([89.107.110.32]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-44fcbd61553sm74260105e9.0.2025.05.29.09.35.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 May 2025 09:35:53 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= <mattias.engdegard@HIDDEN> Subject: Re: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector In-Reply-To: <E7CC8517-E7D3-4507-B9EF-3D396C451E86@HIDDEN> References: <E7CC8517-E7D3-4507-B9EF-3D396C451E86@HIDDEN> Date: Thu, 29 May 2025 18:35:52 +0200 Message-ID: <874ix3l6hj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78620 Cc: Pip Cet <pipcet@HIDDEN>, 78620 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, May 29 2025, Mattias Engdeg=C3=A5rd wrote: [...] > This is the reason why it's written that way, and plenty of > measurements were made at the time. There may still be good arguments > for changing the structure but be careful, and don't do it for > aesthetics alone. Okay, then I withdraw my proposal. Helmut
bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.Received: (at 78620) by debbugs.gnu.org; 29 May 2025 15:02:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 29 11:02:29 2025 Received: from localhost ([127.0.0.1]:37436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uKem5-0007IG-1E for submit <at> debbugs.gnu.org; Thu, 29 May 2025 11:02:29 -0400 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]:52229) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <mattias.engdegard@HIDDEN>) id 1uKem3-0007Hm-45 for 78620 <at> debbugs.gnu.org; Thu, 29 May 2025 11:02:27 -0400 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-553280c345cso1346129e87.0 for <78620 <at> debbugs.gnu.org>; Thu, 29 May 2025 08:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748530940; x=1749135740; darn=debbugs.gnu.org; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=Rwf+IBeCAFo8FLAccp9DyUDsbZEWC+65qZBoWOmI09s=; b=Z8422KihYPhf7UTxrzwC5PJvHCvX0mJ8Ow78jfPsZM1jq4hgfY+s6IGrS+JBdfmLXE YX8Au4uyGoEe8CKzyn0E+tlMsZeelnLYjSVLropLobKBHbILnUrf0gdXKbLxQflMaRyj AHWEUi2aEBuUpWwbTLQ7o9D2nsbEWcifdC3EdJA27NzGmmq1YigT29I5Lrh11R4u7XCk wPTiV/uJa8IN75VjQOPfQm8FBTCnNluUf3dK1dCti2/FJVOpRVyjzTHsxGgrBrjDLksP 34kRdB29FyZ4iFRsk7Ty1yETd/JGOrJG71pplf/L++/yaytZNT+IW/n2w4aEIZF5hhV8 E/Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748530940; x=1749135740; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Rwf+IBeCAFo8FLAccp9DyUDsbZEWC+65qZBoWOmI09s=; b=Oc3wdS5CwEbOxEca06hO+tUDE9oYll0x1vcxGdzTJg8kMvMNpUzj5G3ZN9plQy/aie Ple0LsYTu1vTxkradC96TF9MY8b3SMysMtsb9L5yah0ZM56UymoCCpSZlPMz8N1Pp9/w RcsR2XcpDuOIWj1KPenlUrBiEDb4ktoZSXo/yQDjI3pYDDJ4L8endiKllMhsEqkNZI2R AhQNGsC5/QvatWP/9V+xcI0Y0noNqdLKv+A4O057aAO174EMZmsy3J1fv4/Z2euIneE6 IpysQu9ccvwy9UWuBmM5cZ6WzF45Y9+mXjsAMiE9TA0hW/FlFE5DCd2ZdrvzmedFL739 7BOg== X-Gm-Message-State: AOJu0YyJOyKwUvcBGPtDo64cTgBYLn1HD9sNubjUSE3RQbdX3ez0ylqE xhQDAQzDQKHfUC8Tyh+xC2YR3kYKCix25rwIkJEi/K7kL4rL8u9ehiLK5hpryg== X-Gm-Gg: ASbGnct6dMlXlbcKNkCIEbIsoc+41HkRy57fqOzAxN+YARIstV99MndLKtGL0fXaL9b inK/ZFcFH9BDJfNb/pUfY3x0bX4iFUmwXS5kO82JQ/jS6AdKl+qkcpgaLlFxwj+N17mVyZq2a+m ud/61GzBWfPBl6IKxJxzfMREl/ZEAiwu3zsbWmnl8+4ZTFrOGuPIMjgBw2U6DUuTH+SV6cgM0w5 elUv5B+6nJhh/ykfqQspGwyukXhvMBJqQpJNMwBL7N0boyV4W6PKBBbYOQn2Izq5LOzNbvQRBuV rA+XKH2zPoSGa0YgFblpK9cNFGjtLn9cMskX15HUQTNKiX9cAFzHwQVPNgbadvUf7DTGD8i3gN4 xjAbWyTDGleN5bMFsAkJXpnAkl7zXdoYmdK5muLPEzw== X-Google-Smtp-Source: AGHT+IHAfhdmf3WqQVMnpvv8eS9l0FJ59EtB0I+a8khhsyurrbHVh+dHJ4CTFN7irxydIm8MOzIPBw== X-Received: by 2002:a05:6512:398c:b0:553:3514:1a53 with SMTP id 2adb3069b0e04-55335141c70mr1860611e87.4.1748530938767; Thu, 29 May 2025 08:02:18 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cd92sm346578e87.179.2025.05.29.08.02.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 May 2025 08:02:18 -0700 (PDT) From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattias.engdegard@HIDDEN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector Message-Id: <E7CC8517-E7D3-4507-B9EF-3D396C451E86@HIDDEN> Date: Thu, 29 May 2025 17:02:17 +0200 To: 78620 <at> debbugs.gnu.org X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78620 Cc: Pip Cet <pipcet@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) (I just saw this bug by chance -- if you want my comments on code I = wrote, CC: me explicitly) Thank you for caring about the obarray internals. The reason why the = obarray and hash-table implementations don't use Lisp allocations for = their tables is that with the current GC, it's much more efficient to = allocate and free them explicitly to handle growth. MPS may alter the balance but the concern remains real: eager freeing of = memory immediately when it becomes dead is inherently more = memory-efficient than waiting for it to be collected, and since the = freed memory can be taken into use at once it improves locality. This is the reason why it's written that way, and plenty of measurements = were made at the time. There may still be good arguments for changing = the structure but be careful, and don't do it for aesthetics alone. (And no, I'm not very happy with the internal obarray representation = which was basically kept unchanged when the new obarray objects were = added. Especially the way symbols in each bucket are chained together = with ->next pointers, that's a bit unfortunate. But it works, and is a = lot faster than it was before.)
bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.
Received: (at 78620) by debbugs.gnu.org; 28 May 2025 19:14:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 15:14:18 2025
Received: from localhost ([127.0.0.1]:56734 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uKMED-0003Ze-Mf
for submit <at> debbugs.gnu.org; Wed, 28 May 2025 15:14:18 -0400
Received: from mail-24416.protonmail.ch ([109.224.244.16]:18507)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1uKMEA-0003Z9-8w
for 78620 <at> debbugs.gnu.org; Wed, 28 May 2025 15:14:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1748459646; x=1748718846;
bh=/QhdAYGgF1pzyqhUQtYaUzwgMgen7v/Osu3kJZ72PBY=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
b=W3qWXRdpJA6oRspz1XTSk7oe3nYG96b3RyvIx9JJbllOz85QGwk8nmlpaG56A8SnS
x6meoi0hmJ/TJbNqOqUOaNGaItYn16WURIHCKXP7cyftxGxQmLVyLs2gEt0zrKcb6D
SN1PXb1Yer+igXkpQoiWvrV/ynQQe9HsytrRSZWmyOv+s+liZFMEcyDnAIaOaYoTHI
GA2PMf88UxHkJGYHZ3zt0aSRVrF+cjliNTqdHICXUDQASeHyrNv2zy+EfjQ4EpXxzp
4XyTKx8KqWFSxuUsqTox48spzD3pmvomm8gKtMq2L8a/fr1fQh3YPjmWYpyB7p3zdI
OmqwGR75Vu8EA==
Date: Wed, 28 May 2025 19:14:03 +0000
To: Helmut Eller <eller.helmut@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector
Message-ID: <87seko5z0n.fsf@HIDDEN>
In-Reply-To: <87a56wlly9.fsf@HIDDEN>
References: <87y0uhkkmm.fsf@HIDDEN> <877c207ttl.fsf@HIDDEN>
<87a56wlly9.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: b0cf6e5e3724bc53ee748d3d010c0d01e6763b73
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78620
Cc: 78620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
"Helmut Eller" <eller.helmut@HIDDEN> writes:
> On Wed, May 28 2025, Pip Cet wrote:
>
>> "Helmut Eller" <eller.helmut@HIDDEN> writes:
>>
>>> Making the Lisp_Obarray.buckets field a proper Lisp_Vector instead of a
>>> plain Lisp_Object[] would make some things simpler: some #ifdef HAVE_MP=
S
>>> can be removed and the dumper is a bit simpler too.
>>
>> Or we could make it a Lisp_Object, and use the generic vectorlike code.
>> I really do not understand your reasoning for wanting to do the
>> opposite, and use more raw pointers in heap objects. What is the
>> advantage?
>
> The advantage is better static type checking
Not much of an advantage, given how often we cast pointers in C, and we
give up any hope of automated dynamic type checking.
I'd prefer to dynamically check heap structures have the right type in
(another user of) the shared tracing code you suggested. It might not
have been obvious, but, to me, edge naming implies edge typechecking,
and this is what I wrote:
case PVEC_OVERLAY:
EDGES (EDGE_PLIST (plist));
case PVEC_FINALIZER:
EDGES (EDGE_FUNCTION (function));
case PVEC_SYMBOL_WITH_POS:
EDGES (EDGE_BARE_SYMBOL (sym),
=09 EDGE_FIXNUM (pos));
Please ignore that the edge list should be closer to the struct
definition. Let's focus on the benefits of having a simple option to
trace the heap (continuously in a background thread if we must) and
verify that every finalizer's "function" field satisfies FUNCTIONP
(let's pretend the nil case doesn't happen right now). I don't see how
we could even do that statically.
So we can do better than limited static typechecking if we use
Lisp_Objects and predicates rather than C pointers and C types, IMHO.
> and better documentation.
Not really:
> Compare the field declarations:
>
> struct Lisp_Vector *buckets;
>
> with
>
> Lisp_Object buckets;
>
> Which one describes the data structure better? Clearly the first.
Neither one describes it particularly well, though. Is buckets allowed
to be NULL? What's the size of buckets? Is it a real Lisp_Vector or a
pointer to a vectorlike cast to struct Lisp_Vector * for convenience?
So we need to compare
struct Lisp_Vector *buckets; /* A real Lisp vector, never NULL. */
to
Lisp_Object buckets; /* A vector. */
>> I realize there's no consensus for following my suggestion (if it's on
>> the heap, and thus fixable, use a Lisp_Object; if you need a raw
>> pointer, it should only ever be in a local variable). But I don't think
>> there's any consensus for doing the opposite either.
>
> I think that in structures, raw pointers to objects on the GC heap will
> not go away.
> So we can as well take advantage of them.
I think we'd be giving up the advantages of strict,
dynamically-verified, rich predicates, and all we get is plain old C
typechecks which can be fooled by a simple pointer cast (or, worse,
cannot be, necessitating many more near-equivalent definitions).
> Valid points. See amended patch below.
My opinion (which doesn't count for anything): Replacing Lisp_Object
*buckets by struct Lisp_Vector *buckets is an improvement. Replacing
it by Lisp_Object buckets would be a more significant improvement.
Modifying the generic code doesn't improve things: more definitions to
learn, and ASIZE/vector_size are confusingly different now.
>=C2=A0+ eassert ((1 << o->size_bits) =3D=3D (size_t) vector_size (o->buck=
ets));
will break for o->size_bits =3D 32, I think.
My suggestion would be to apply this without introducing the API
doublets, spelling out v->contents[idx] as we do elsewhere.
Pip
bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.
Received: (at 78620) by debbugs.gnu.org; 28 May 2025 16:49:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 12:49:56 2025
Received: from localhost ([127.0.0.1]:55635 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uKJyS-0005qp-EE
for submit <at> debbugs.gnu.org; Wed, 28 May 2025 12:49:56 -0400
Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:53294)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1uKJyJ-0005pM-GO
for 78620 <at> debbugs.gnu.org; Wed, 28 May 2025 12:49:49 -0400
Received: by mail-wm1-x330.google.com with SMTP id
5b1f17b1804b1-450ccda1a6eso744515e9.2
for <78620 <at> debbugs.gnu.org>; Wed, 28 May 2025 09:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748450977; x=1749055777; darn=debbugs.gnu.org;
h=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=VcU1uFh9TVJsZ7FoRtheGnQj/DY/YtNsPI9HgfVC1Ow=;
b=Hy3sRGbt0kF7jRqyxX0DOAXDNCw4zuJ8S1Wx14RIaffjcyDIZrlb5YA4fRIDntTha9
jFXI1N+bVAf5DqFmRE8o6Lv9Jh29CG6HlqHzpsAtUgJPH88/dhzwFN71h8GSA3rj/q7Z
J8dLkiq7x28EjGt8Jw9fQtmTPt7SBE08PQJwW6ui2HYSibsi7K6RB9Z+abWG+XWVfqt7
LycTQyBDwbJW9U+7mr6ynYTZveuEEJtexLs972MyRRo2CTxdpFN07NFrdSkNdFvZkZ7r
WbEmdu7JH7IU+YUYRHgG4pBvsCQWwnz7V2rC1E48BWvupDQgcfEsxOESSw4tOQozxfPa
7TWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748450977; x=1749055777;
h=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=VcU1uFh9TVJsZ7FoRtheGnQj/DY/YtNsPI9HgfVC1Ow=;
b=kjJynVW32TFH0pBPBch2aEqbftBRwUI1kneMb8immr01eCd6xOr/x2fT5Eov9jTLT3
sFtWKL59MpRDmrOiMuFKqdOr/Q9DXsXV6Eu2HDt0RSRGzojQU9WuC+0SvK7tHV/Uk/QP
iPVoCnLZxTLR8tCRwNzbmRt+UKzcAcey+WaKSmM+0nERnUhg0JFd23qNSca5zijKMn6e
F552jpKT7PrDj6dPUGk9ffNLkigH2qYt+MwuNYBkYHRMuzy9zgvVX9hZaY5P0XVK5KFN
Z8LTMDpWADSGPP7q/HcBgMpXB+O38Ej5N3xnFOXwyOGs7VySNvRKckbeGa6FzyxeYb0T
kqJA==
X-Gm-Message-State: AOJu0YwN0qsfFbG9B85Haea59o5jf9kvTCSvK0H9R66EPoe0QTZhMO0A
ucnCz4Az4DyLdNkSeybHwHitoD+9AXqBTyR166yvXob2CURLolFVmSI0TWrLjg==
X-Gm-Gg: ASbGncvxur98dYEuGn/wrfPbUdqy3flGhCw/YD1k5hXZE4b0ja+8obdnaVbtbL7OaHh
D10MCUNs2AkCd6+hGI/dIuGy/s8hbCsSsHmASNNyJ5hwd1enz3GoUICnRv1ROxPXnFa0kZB/ju+
1zqimeCnpvuzYFHvWwzKjM3Aia6CmwJvHuCIr1stPvPtG/5b96ZfLXRW6n05hQrJuUZh0pIcxLp
jsCjpD8CTIkxkqOv0F45MtqP/GifHJzAbcqdgeSUcfa4HFGXp/fLOtW1gOIaby+5kDdZqBJeIAH
ste5ymFCA8H9C+EioSCVqrU5y1V4Vm3uEdydEaji02YyUlxj
X-Google-Smtp-Source: AGHT+IHn7MFu2/DqPe0Nqp6jBcaERrlHEMlkMlWbpzdtMYxRpB2cM/ONgLhY+VLhMvcJJ27pkh5gLA==
X-Received: by 2002:a05:6000:18ad:b0:3a4:d994:be4b with SMTP id
ffacd0b85a97d-3a4d994bfa2mr11733425f8f.1.1748450976882;
Wed, 28 May 2025 09:49:36 -0700 (PDT)
Received: from caladan ([89.107.110.32]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-3a4eace3a76sm1957966f8f.98.2025.05.28.09.49.36
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 28 May 2025 09:49:36 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector
In-Reply-To: <877c207ttl.fsf@HIDDEN>
References: <87y0uhkkmm.fsf@HIDDEN> <877c207ttl.fsf@HIDDEN>
Date: Wed, 28 May 2025 18:49:34 +0200
Message-ID: <87a56wlly9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78620
Cc: 78620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
On Wed, May 28 2025, Pip Cet wrote:
> "Helmut Eller" <eller.helmut@HIDDEN> writes:
>
>> Making the Lisp_Obarray.buckets field a proper Lisp_Vector instead of a
>> plain Lisp_Object[] would make some things simpler: some #ifdef HAVE_MPS
>> can be removed and the dumper is a bit simpler too.
>
> Or we could make it a Lisp_Object, and use the generic vectorlike code.
> I really do not understand your reasoning for wanting to do the
> opposite, and use more raw pointers in heap objects. What is the
> advantage?
The advantage is better static type checking and better documentation.
Compare the field declarations:
struct Lisp_Vector *buckets;
with
Lisp_Object buckets;
Which one describes the data structure better? Clearly the first.
[...]
> I realize there's no consensus for following my suggestion (if it's on
> the heap, and thus fixable, use a Lisp_Object; if you need a raw
> pointer, it should only ever be in a local variable). But I don't think
> there's any consensus for doing the opposite either.
I think that in structures, raw pointers to objects on the GC heap will
not go away. So we can as well take advantage of them.
[...]
> As for less fundamental things that should probably be fixed:
>
> I notice that vector_size doesn't mask out the GC mark bit, but it is
> used instead of gc_asize in the new AREF. So the new AREF is
> problematic when used during GC.
[...]
> The pdumper code should probably use strong weight for the bucket
> vector, not WEIGHT_NORMAL, in order to avoid changing the dump layout
> unpredictably.
[...]
> Since size_bits and the size of the new vectors are redundant, it'd be
> nice to assert things are as they should be in obarray_size.
Valid points. See amended patch below.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0001-Make-obarray-s-buckets-a-Lisp_Vector.patch
From bffe953c86eacbeb56327aa71846f77ee483ec95 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Wed, 28 May 2025 11:11:52 +0200
Subject: [PATCH] Make obarray's buckets a Lisp_Vector
This unifies the GC code and simplifies the dumper.
* src/lisp.h (struct Lisp_Obarray): Turn the buckets field into struct
Lisp_Vector *.
(vector_ref, vector_set, vector_size): New utilties.
(obarray_iter_at_end): Use vector_ref.
* src/lread.c (intern_sym, Funintern, oblookup, make_obarray)
(grow_obarray, Fobarray_clear, Finternal__obarray_buckets): Adapt
to vectors.
* src/igc.c (vectorlike_size): Renamed from vector_size.
(fix_obarray): Adapt to vectors.
* src/alloc.c (process_mark_stack): Adapt to vectors.
(cleanup_vector): Nothing special to do for obarrays.
* src/pdumper.c (dump_obarray): Adapt to vectors.
(dump_obarray_buckets): Deleted.
---
src/alloc.c | 11 ++------
src/igc.c | 12 ++++-----
src/lisp.h | 25 ++++++++++++++++--
src/lread.c | 73 ++++++++++++++++++---------------------------------
src/pdumper.c | 15 +++--------
5 files changed, 60 insertions(+), 76 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index ceda62f5ed6..0eb9cd91f89 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -3359,14 +3359,6 @@ cleanup_vector (struct Lisp_Vector *vector)
}
}
break;
- case PVEC_OBARRAY:
- {
- struct Lisp_Obarray *o = PSEUDOVEC_STRUCT (vector, Lisp_Obarray);
- xfree (o->buckets);
- ptrdiff_t bytes = obarray_size (o) * sizeof *o->buckets;
- hash_table_allocated_bytes -= bytes;
- }
- break;
/* Keep the switch exhaustive. */
case PVEC_NORMAL_VECTOR:
case PVEC_FREE:
@@ -3377,6 +3369,7 @@ cleanup_vector (struct Lisp_Vector *vector)
case PVEC_BOOL_VECTOR:
case PVEC_BUFFER:
case PVEC_PROCESS:
+ case PVEC_OBARRAY:
case PVEC_TERMINAL:
case PVEC_WINDOW_CONFIGURATION:
case PVEC_OTHER:
@@ -6864,7 +6857,7 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0)
{
struct Lisp_Obarray *o = (struct Lisp_Obarray *)ptr;
set_vector_marked (ptr);
- mark_stack_push_values (o->buckets, obarray_size (o));
+ mark_vectorlike (&o->buckets->header);
break;
}
diff --git a/src/igc.c b/src/igc.c
index 9c3c8e82758..1418de102e5 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -202,7 +202,7 @@
# ifndef HASH_face_cache_C289FB8D72
# error "struct face_cache changed"
# endif
-# ifndef HASH_Lisp_Obarray_29CFFD1B74
+# ifndef HASH_Lisp_Obarray_3BA8AFA3DB
# error "struct Lisp_Obarray changed"
# endif
# ifndef HASH_module_global_reference_85FFC23A88
@@ -1101,7 +1101,7 @@ deregister_thread (struct igc_thread_list *t)
#pragma GCC diagnostic ignored "-Wunused-variable"
static size_t
-vector_size (const struct Lisp_Vector *v)
+vectorlike_size (const struct Lisp_Vector *v)
{
size_t size = v->header.size;
if (size & PSEUDOVECTOR_FLAG)
@@ -2129,7 +2129,7 @@ fix_vectorlike (mps_ss_t ss, struct Lisp_Vector *v)
{
MPS_SCAN_BEGIN (ss)
{
- size_t size = vector_size (v);
+ size_t size = vectorlike_size (v);
IGC_FIX12_NOBJS (ss, v->contents, size);
}
MPS_SCAN_END (ss);
@@ -2432,7 +2432,7 @@ fix_char_table (mps_ss_t ss, struct Lisp_Vector *v)
{
MPS_SCAN_BEGIN (ss)
{
- for (size_t i = vector_start (v), n = vector_size (v); i < n; ++i)
+ for (size_t i = vector_start (v), n = vectorlike_size (v); i < n; ++i)
IGC_FIX12_OBJ (ss, &v->contents[i]);
}
MPS_SCAN_END (ss);
@@ -2665,7 +2665,7 @@ fix_obarray (mps_ss_t ss, struct Lisp_Obarray *o)
{
MPS_SCAN_BEGIN (ss)
{
- IGC_FIX12_WRAPPED_VEC (ss, &o->buckets);
+ IGC_FIX12_PVEC (ss, &o->buckets);
}
MPS_SCAN_END (ss);
return MPS_RES_OK;
@@ -3471,7 +3471,7 @@ finalize_bignum (struct Lisp_Bignum *n)
finalize_font (struct font *font)
{
struct Lisp_Vector *v = (void *) font;
- if (vector_size (v) == FONT_OBJECT_MAX)
+ if (vectorlike_size (v) == FONT_OBJECT_MAX)
{
/* The font driver might sometimes be NULL, e.g. if Emacs was
interrupted before it had time to set it up. */
diff --git a/src/lisp.h b/src/lisp.h
index 315ff89f391..2774386aad1 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -2069,6 +2069,27 @@ gc_aset (Lisp_Object array, ptrdiff_t idx, Lisp_Object val)
XVECTOR (array)->contents[idx] = val;
}
+INLINE ptrdiff_t
+vector_size (const struct Lisp_Vector *v)
+{
+ eassert (!(v->header.size & PSEUDOVECTOR_FLAG));
+ return v->header.size & ~ARRAY_MARK_FLAG;
+}
+
+INLINE Lisp_Object
+vector_ref (const struct Lisp_Vector *v, ptrdiff_t idx)
+{
+ eassert (0 <= idx && idx < vector_size (v));
+ return v->contents[idx];
+}
+
+INLINE void
+vector_set (struct Lisp_Vector *v, ptrdiff_t idx, Lisp_Object val)
+{
+ eassert (0 <= idx && idx < vector_size (v));
+ v->contents[idx] = val;
+}
+
/* True, since Qnil's representation is zero. Every place in the code
that assumes Qnil is zero should static_assert (NIL_IS_ZERO), to make
it easy to find such assumptions later if we change Qnil to be
@@ -2482,7 +2503,7 @@ #define DEFSYM(sym, name) /* empty */
/* Array of 2**size_bits values, each being either a (bare) symbol or
the fixnum 0. The symbols for each bucket are chained via
their s.next field. */
- Lisp_Object *buckets;
+ struct Lisp_Vector *buckets;
unsigned size_bits; /* log2(size of buckets vector) */
unsigned count; /* number of symbols in obarray */
@@ -2558,7 +2579,7 @@ obarray_iter_at_end (obarray_iter_t *it)
ptrdiff_t size = obarray_size (it->o);
while (++it->idx < size)
{
- Lisp_Object obj = it->o->buckets[it->idx];
+ Lisp_Object obj = vector_ref (it->o->buckets, it->idx);
if (!BASE_EQ (obj, make_fixnum (0)))
{
it->symbol = XBARE_SYMBOL (obj);
diff --git a/src/lread.c b/src/lread.c
index a248c8f5ed9..07ff5367fec 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4903,9 +4903,10 @@ intern_sym (Lisp_Object sym, Lisp_Object obarray, Lisp_Object index)
}
struct Lisp_Obarray *o = XOBARRAY (obarray);
- Lisp_Object *ptr = o->buckets + XFIXNUM (index);
- s->u.s.next = BARE_SYMBOL_P (*ptr) ? XBARE_SYMBOL (*ptr) : NULL;
- *ptr = sym;
+ ptrdiff_t idx = XFIXNUM (index);
+ Lisp_Object entry = vector_ref (o->buckets, idx);
+ s->u.s.next = BARE_SYMBOL_P (entry) ? XBARE_SYMBOL (entry) : NULL;
+ vector_set (o->buckets, idx, sym);
o->count++;
if (o->count > obarray_size (o))
grow_obarray (o);
@@ -5113,12 +5114,17 @@ DEFUN ("unintern", Funintern, Sunintern, 2, 2, 0,
sym->u.s.interned = SYMBOL_UNINTERNED;
ptrdiff_t idx = oblookup_last_bucket_number;
- Lisp_Object *loc = &XOBARRAY (obarray)->buckets[idx];
+ struct Lisp_Vector *buckets = XOBARRAY (obarray)->buckets;
+ Lisp_Object entry = vector_ref (buckets, idx);
- eassert (BARE_SYMBOL_P (*loc));
- struct Lisp_Symbol *prev = XBARE_SYMBOL (*loc);
+ eassert (BARE_SYMBOL_P (entry));
+ struct Lisp_Symbol *prev = XBARE_SYMBOL (entry);
if (sym == prev)
- *loc = sym->u.s.next ? make_lisp_symbol (sym->u.s.next) : make_fixnum (0);
+ {
+ Lisp_Object val
+ = sym->u.s.next ? make_lisp_symbol (sym->u.s.next) : make_fixnum (0);
+ vector_set (buckets, idx, val);
+ }
else
while (1)
{
@@ -5157,7 +5163,7 @@ oblookup (Lisp_Object obarray, register const char *ptr, ptrdiff_t size, ptrdiff
{
struct Lisp_Obarray *o = XOBARRAY (obarray);
ptrdiff_t idx = obarray_index (o, ptr, size_byte);
- Lisp_Object bucket = o->buckets[idx];
+ Lisp_Object bucket = vector_ref (o->buckets, idx);
oblookup_last_bucket_number = idx;
if (!BASE_EQ (bucket, make_fixnum (0)))
@@ -5255,13 +5261,8 @@ make_obarray (unsigned bits)
o->count = 0;
o->size_bits = bits;
ptrdiff_t size = (ptrdiff_t)1 << bits;
-#ifdef HAVE_MPS
- o->buckets = hash_table_alloc_kv (o, size);
-#else
- o->buckets = hash_table_alloc_bytes (size * sizeof *o->buckets);
-#endif
- for (ptrdiff_t i = 0; i < size; i++)
- o->buckets[i] = make_fixnum (0);
+ o->buckets = XVECTOR (make_vector (size, make_fixnum (0)));
+ eassert ((1 << o->size_bits) == (size_t) vector_size (o->buckets));
return make_lisp_obarray (o);
}
@@ -5277,19 +5278,13 @@ grow_obarray (struct Lisp_Obarray *o)
{
ptrdiff_t old_size = obarray_size (o);
eassert (o->count > old_size);
- Lisp_Object *old_buckets = o->buckets;
+ struct Lisp_Vector *old_buckets = o->buckets;
int new_bits = o->size_bits + 1;
if (new_bits > obarray_max_bits)
error ("Obarray too big");
ptrdiff_t new_size = (ptrdiff_t) 1 << new_bits;
-#ifdef HAVE_MPS
- o->buckets = hash_table_alloc_kv (o, new_size);
-#else
- o->buckets = hash_table_alloc_bytes (new_size * sizeof *o->buckets);
-#endif
- for (ptrdiff_t i = 0; i < new_size; i++)
- o->buckets[i] = make_fixnum (0);
+ o->buckets = XVECTOR (make_vector (new_size, make_fixnum (0)));
o->size_bits = new_bits;
/* Rehash symbols.
@@ -5297,7 +5292,7 @@ grow_obarray (struct Lisp_Obarray *o)
symbol name. Would it be reasonable to store it in the symbol? */
for (ptrdiff_t i = 0; i < old_size; i++)
{
- Lisp_Object obj = old_buckets[i];
+ Lisp_Object obj = vector_ref (old_buckets, i);
if (BARE_SYMBOL_P (obj))
{
struct Lisp_Symbol *s = XBARE_SYMBOL (obj);
@@ -5305,18 +5300,17 @@ grow_obarray (struct Lisp_Obarray *o)
{
Lisp_Object name = s->u.s.name;
ptrdiff_t idx = obarray_index (o, SSDATA (name), SBYTES (name));
- Lisp_Object *loc = o->buckets + idx;
+ Lisp_Object sym = vector_ref (o->buckets, idx);
struct Lisp_Symbol *next = s->u.s.next;
- s->u.s.next = BARE_SYMBOL_P (*loc) ? XBARE_SYMBOL (*loc) : NULL;
- *loc = make_lisp_symbol (s);
+ s->u.s.next = BARE_SYMBOL_P (sym) ? XBARE_SYMBOL (sym) : NULL;
+ vector_set (o->buckets, idx, make_lisp_symbol (s));
if (next == NULL)
break;
s = next;
}
}
}
-
- hash_table_free_kv (o, old_buckets, old_size);
+ eassert ((1 << o->size_bits) == (size_t) vector_size (o->buckets));
}
DEFUN ("obarray-make", Fobarray_make, Sobarray_make, 0, 1, 0,
@@ -5357,25 +5351,10 @@ DEFUN ("obarray-clear", Fobarray_clear, Sobarray_clear, 1, 1, 0,
to uninterned. It doesn't matter very much. */
int new_bits = obarray_default_bits;
int new_size = (ptrdiff_t)1 << new_bits;
-#ifdef HAVE_MPS
- Lisp_Object *new_buckets = hash_table_alloc_kv (o, new_size);
-#else
- Lisp_Object *new_buckets
- = hash_table_alloc_bytes (new_size * sizeof *new_buckets);
-#endif
- for (ptrdiff_t i = 0; i < new_size; i++)
- new_buckets[i] = make_fixnum (0);
-
-#ifdef HAVE_MPS
- hash_table_free_kv (o, o->buckets, -1 /* ignored */);
-#else
- int old_size = obarray_size (o);
- hash_table_free_bytes (o->buckets, old_size * sizeof *o->buckets);
-#endif
- o->buckets = new_buckets;
+ o->buckets = XVECTOR (make_vector (new_size, make_fixnum (0)));
o->size_bits = new_bits;
o->count = 0;
-
+ eassert ((1 << o->size_bits) == (size_t) vector_size (o->buckets));
return Qnil;
}
@@ -5418,7 +5397,7 @@ DEFUN ("internal--obarray-buckets",
for (ptrdiff_t i = 0; i < size; i++)
{
Lisp_Object bucket = Qnil;
- Lisp_Object sym = XOBARRAY (obarray)->buckets[i];
+ Lisp_Object sym = vector_ref (XOBARRAY (obarray)->buckets, i);
if (BARE_SYMBOL_P (sym))
while (1)
{
diff --git a/src/pdumper.c b/src/pdumper.c
index d73a0704e20..c7e72f62b11 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2857,16 +2857,10 @@ dump_weak_hash_table (struct dump_context *ctx, Lisp_Object object)
}
#endif
-static dump_off
-dump_obarray_buckets (struct dump_context *ctx, const struct Lisp_Obarray *o)
-{
- return dump_hash_vec (ctx, o->buckets, obarray_size (o));
-}
-
static dump_off
dump_obarray (struct dump_context *ctx, Lisp_Object object)
{
-#if CHECK_STRUCTS && !defined HASH_Lisp_Obarray_29CFFD1B74
+#if CHECK_STRUCTS && !defined HASH_Lisp_Obarray_3BA8AFA3DB
# error "Lisp_Obarray changed. See CHECK_STRUCTS comment in config.h."
#endif
const struct Lisp_Obarray *in_oa = XOBARRAY (object);
@@ -2877,12 +2871,9 @@ dump_obarray (struct dump_context *ctx, Lisp_Object object)
dump_pseudovector_lisp_fields (ctx, &out->header, &oa->header);
DUMP_FIELD_COPY (out, oa, count);
DUMP_FIELD_COPY (out, oa, size_bits);
- dump_field_fixup_later (ctx, out, oa, &oa->buckets);
+ dump_field_lv_rawptr (ctx, out, oa, &oa->buckets, Lisp_Vectorlike,
+ WEIGHT_STRONG);
dump_off offset = finish_dump_pvec (ctx, &out->header);
- dump_remember_fixup_ptr_raw
- (ctx,
- offset + dump_offsetof (struct Lisp_Obarray, buckets),
- dump_obarray_buckets (ctx, oa));
return offset;
}
--
2.39.5
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.Received: (at 78620) by debbugs.gnu.org; 28 May 2025 13:23:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 09:23:42 2025 Received: from localhost ([127.0.0.1]:52231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uKGkt-0001VC-A3 for submit <at> debbugs.gnu.org; Wed, 28 May 2025 09:23:42 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:18713) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1uKGko-0001U1-8a for 78620 <at> debbugs.gnu.org; Wed, 28 May 2025 09:23:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1748438606; x=1748697806; bh=I0vrZol6JHjmfgzHp7/3OYbM53FMc17XcD3bg/9NwNw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=fG+JD/RcI3BUvYGYNzWNGsL0c8OE+7Fdia/E1w7anPHf3p9gRjQRPYJbb/L7M7H3/ I6n0YX8oUvyeKel5I8tD/mtAgDdhgQ90krg8m0OdAp9Pc/lBPy2HNcUSlYOjCwGWV1 RFrpNrFfbsq1vmo5r6sY++hGHjLbgPxoAJLnCPfd1xyIztv78tvvhRerN8qk1bXPpi mjCB87QOMLeR2sUPvkeHsrt/opDbFOnkqzBQGH/3t8PE4jHebIrS+Jngk4MrCcu/4j MmLNRBPxZVlP4slzMeypF7Pud2IJRcBIW7MiBJ+XJ09njEvRubg/DXmQSzVv+U+Jkf hlpjVYLJN9vUg== Date: Wed, 28 May 2025 13:23:23 +0000 To: Helmut Eller <eller.helmut@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector Message-ID: <877c207ttl.fsf@HIDDEN> In-Reply-To: <87y0uhkkmm.fsf@HIDDEN> References: <87y0uhkkmm.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4479674e3b6995fb56fb1386922aa5fa4aadf97d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78620 Cc: 78620 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Helmut Eller" <eller.helmut@HIDDEN> writes: > Making the Lisp_Obarray.buckets field a proper Lisp_Vector instead of a > plain Lisp_Object[] would make some things simpler: some #ifdef HAVE_MPS > can be removed and the dumper is a bit simpler too. Or we could make it a Lisp_Object, and use the generic vectorlike code. I really do not understand your reasoning for wanting to do the opposite, and use more raw pointers in heap objects. What is the advantage? It's less type-safe, cannot be done in many places, and generally makes hacking harder. The code size impact is small on x86 and should be minimal on aarch64. I realize there's no consensus for following my suggestion (if it's on the heap, and thus fixable, use a Lisp_Object; if you need a raw pointer, it should only ever be in a local variable). But I don't think there's any consensus for doing the opposite either. But all this may well mean I'm missing the point here. > The patch introduces functions vector_ref/vector_set which are analogues > to AREF/ASET; maybe that is contentious. Again, I don't understand the impulse behind avoiding Lisp_Objects. As for less fundamental things that should probably be fixed: I notice that vector_size doesn't mask out the GC mark bit, but it is used instead of gc_asize in the new AREF. So the new AREF is problematic when used during GC. The pdumper code should probably use strong weight for the bucket vector, not WEIGHT_NORMAL, in order to avoid changing the dump layout unpredictably. Since size_bits and the size of the new vectors are redundant, it'd be nice to assert things are as they should be in obarray_size. Pip
bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 28 May 2025 12:04:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 08:04:03 2025
Received: from localhost ([127.0.0.1]:51636 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uKFVp-0007y5-KB
for submit <at> debbugs.gnu.org; Wed, 28 May 2025 08:04:02 -0400
Received: from lists.gnu.org ([2001:470:142::17]:54940)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1uKFVm-0007wm-5A
for submit <at> debbugs.gnu.org; Wed, 28 May 2025 08:03:59 -0400
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 <eller.helmut@HIDDEN>)
id 1uKFVV-0006Fd-IW
for bug-gnu-emacs@HIDDEN; Wed, 28 May 2025 08:03:45 -0400
Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <eller.helmut@HIDDEN>)
id 1uKFVP-00024Y-2z
for bug-gnu-emacs@HIDDEN; Wed, 28 May 2025 08:03:39 -0400
Received: by mail-ej1-x629.google.com with SMTP id
a640c23a62f3a-ad8a8da2376so35906366b.3
for <bug-gnu-emacs@HIDDEN>; Wed, 28 May 2025 05:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748433813; x=1749038613; darn=gnu.org;
h=mime-version:user-agent:message-id:date:subject:to:from:from:to:cc
:subject:date:message-id:reply-to;
bh=sOGpbAhO/rUY0E7XqbNerofgD9aVSTI9qzP48uousg0=;
b=RB92S4Nq25Z31xu3pmCeVbtsn+yJJfsUgjDEShHMwGm2SjWdfSy8OYoVeksIIYqKSs
f4+j1lekvod+kCgd1U8fsFQ+7YFlIyOwY0Tuxgf9sE5gfU6c7v6TVgqSRfVbYFl/dDgf
XmtGYPt7Eu+btXAIRDIZMRLyqZPHsZGJqlpiOEs1zCKtfl9+CadXMyPv3HnUG8x9Mmm7
6pAKe/RWyddpD0wlJy+0nmjwNt9qArA3zY/lrtoLkcNq2E4g7Ogd+rzq5JDD4LMNpb4L
N1BqZxlJYOZosGYWay5j3Qw8XcR+Z2o/QtWNNxlegOQppMtKLss6ddmI95dVHwpx4sAR
AgfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748433813; x=1749038613;
h=mime-version:user-agent:message-id:date:subject:to:from
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=sOGpbAhO/rUY0E7XqbNerofgD9aVSTI9qzP48uousg0=;
b=pYQe9s0Ehr6CjA7pLYEOa7e01ImcZigFYGYaUgkJdvHwBKu8Rg70w8fFsNB5IfIEwt
x5FvBsJNd4y9W86gkBiTtrwFWNDJNpuVvBzdgYxk/ycATReMl1vTQPHUfl08uVE2FvPE
awtk53sqGVxqXeerBzQpGAR/qw8+ddLizidjMc+APDqAdy63ZgWPURdV5qFYh48D25Ar
xkOsCjP1bDFOoJJALsZtcJ/FjEDUPGWOy+5PJtZbjrjlG19rBCQQK5Qi78PfTJyHJu74
VfccPzdMdVVliWws2GPSDCaBee2opD4JPBG78zqPH6EmfNnsdCC7qSioKxWD/g2+h1JJ
jTZA==
X-Gm-Message-State: AOJu0YzFLQez2hVZrj2wr5dNRmT5/KK12k8qlUDxgb2Taa581Wi/n0yz
EFDh29mRRY8kcis7Keq5GGj1KFbDtgMDxjw/SOLHD+EBFCKLyya6+9lN4z8eGA==
X-Gm-Gg: ASbGncvnxxQXQV3Xq+CY4ULPgaDk57yL9kwfEEq4dh/N20GIPlafAZ2sS1LazMi30h8
ty1SdGZMXZW27Wvuakm9xmJiy/hP2mGvTbuOqMEGdCRYVfA5HDCanQAOKV3x/Xpo6h6NY20Q7yt
VK904DXHjGHZP9k/dqXvK4aBw029i24iYvqz0iALdR7rqEZFGc6LvOlHpqdwG5+DjkE5idhJld3
DUX4T4cBqf/620t/s/1BK4iiQPecUV0tvhTDkPXApbasmdeeyeg7SXFiRQXgAfxh8/VDPRGGbHz
ccbAGbcFmteHjlR6TFdRVbEX55XIcF0ouCDrt5K0PO4JKIaF
X-Google-Smtp-Source: AGHT+IGe5aPRdYAL51pjF0ho/hBvlqmMMFcxVFqLAqqKqp5SDFkoZNKuyUWy2i/S/JjCCreyCP8Wgw==
X-Received: by 2002:a17:907:7252:b0:ad2:4d69:6da5 with SMTP id
a640c23a62f3a-ad85b213577mr1323420366b.57.1748433810676;
Wed, 28 May 2025 05:03:30 -0700 (PDT)
Received: from caladan ([89.107.110.32]) by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-ad8a19ca429sm98230666b.64.2025.05.28.05.03.29
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 28 May 2025 05:03:29 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Make obarray's buckets a Lisp_Vector
X-Debbugs-Cc:
Date: Wed, 28 May 2025 14:03:29 +0200
Message-ID: <87y0uhkkmm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::629;
envelope-from=eller.helmut@HIDDEN; helo=mail-ej1-x629.google.com
X-Spam_score_int: -1
X-Spam_score: -0.2
X-Spam_bar: /
X-Spam_report: (-0.2 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--=-=-=
Content-Type: text/plain
Making the Lisp_Obarray.buckets field a proper Lisp_Vector instead of a
plain Lisp_Object[] would make some things simpler: some #ifdef HAVE_MPS
can be removed and the dumper is a bit simpler too.
The patch introduces functions vector_ref/vector_set which are analogues
to AREF/ASET; maybe that is contentious.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0001-Make-obarray-s-buckets-a-Lisp_Vector.patch
From 9859e9d2b4861f3fbda2c1b444049a72c6f82291 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Wed, 28 May 2025 11:11:52 +0200
Subject: [PATCH] Make obarray's buckets a Lisp_Vector
This unifies the GC code and simplifies the dumper.
* src/lisp.h (struct Lisp_Obarray): Turn the buckets field into a
struct Lisp_Vector *.
(vector_ref, vector_set, vector_size): New utilties.
(AREF, ASET, ASIZE): Use them.
(obarray_iter_at_end): Use vector_ref.
* src/lread.c (intern_sym, Funintern, oblookup, make_obarray)
(grow_obarray, Fobarray_clear, Finternal__obarray_buckets): Adapt
to vectors.
* src/igc.c (vectorlike_size): Renamed from vector_size.
(fix_obarray): Adapt to vectors.
* src/alloc.c (process_mark_stack): Adapt to vectors.
(cleanup_vector): Nothing special to do for obarrays.
* src/pdumper.c (dump_obarray): Adapt to vectors.
(dump_obarray_buckets): Deleted.
---
src/alloc.c | 11 ++------
src/igc.c | 12 ++++-----
src/lisp.h | 34 +++++++++++++++++++------
src/lread.c | 69 +++++++++++++++++----------------------------------
src/pdumper.c | 15 +++--------
5 files changed, 60 insertions(+), 81 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index ceda62f5ed6..0eb9cd91f89 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -3359,14 +3359,6 @@ cleanup_vector (struct Lisp_Vector *vector)
}
}
break;
- case PVEC_OBARRAY:
- {
- struct Lisp_Obarray *o = PSEUDOVEC_STRUCT (vector, Lisp_Obarray);
- xfree (o->buckets);
- ptrdiff_t bytes = obarray_size (o) * sizeof *o->buckets;
- hash_table_allocated_bytes -= bytes;
- }
- break;
/* Keep the switch exhaustive. */
case PVEC_NORMAL_VECTOR:
case PVEC_FREE:
@@ -3377,6 +3369,7 @@ cleanup_vector (struct Lisp_Vector *vector)
case PVEC_BOOL_VECTOR:
case PVEC_BUFFER:
case PVEC_PROCESS:
+ case PVEC_OBARRAY:
case PVEC_TERMINAL:
case PVEC_WINDOW_CONFIGURATION:
case PVEC_OTHER:
@@ -6864,7 +6857,7 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0)
{
struct Lisp_Obarray *o = (struct Lisp_Obarray *)ptr;
set_vector_marked (ptr);
- mark_stack_push_values (o->buckets, obarray_size (o));
+ mark_vectorlike (&o->buckets->header);
break;
}
diff --git a/src/igc.c b/src/igc.c
index 9c3c8e82758..1418de102e5 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -202,7 +202,7 @@
# ifndef HASH_face_cache_C289FB8D72
# error "struct face_cache changed"
# endif
-# ifndef HASH_Lisp_Obarray_29CFFD1B74
+# ifndef HASH_Lisp_Obarray_3BA8AFA3DB
# error "struct Lisp_Obarray changed"
# endif
# ifndef HASH_module_global_reference_85FFC23A88
@@ -1101,7 +1101,7 @@ deregister_thread (struct igc_thread_list *t)
#pragma GCC diagnostic ignored "-Wunused-variable"
static size_t
-vector_size (const struct Lisp_Vector *v)
+vectorlike_size (const struct Lisp_Vector *v)
{
size_t size = v->header.size;
if (size & PSEUDOVECTOR_FLAG)
@@ -2129,7 +2129,7 @@ fix_vectorlike (mps_ss_t ss, struct Lisp_Vector *v)
{
MPS_SCAN_BEGIN (ss)
{
- size_t size = vector_size (v);
+ size_t size = vectorlike_size (v);
IGC_FIX12_NOBJS (ss, v->contents, size);
}
MPS_SCAN_END (ss);
@@ -2432,7 +2432,7 @@ fix_char_table (mps_ss_t ss, struct Lisp_Vector *v)
{
MPS_SCAN_BEGIN (ss)
{
- for (size_t i = vector_start (v), n = vector_size (v); i < n; ++i)
+ for (size_t i = vector_start (v), n = vectorlike_size (v); i < n; ++i)
IGC_FIX12_OBJ (ss, &v->contents[i]);
}
MPS_SCAN_END (ss);
@@ -2665,7 +2665,7 @@ fix_obarray (mps_ss_t ss, struct Lisp_Obarray *o)
{
MPS_SCAN_BEGIN (ss)
{
- IGC_FIX12_WRAPPED_VEC (ss, &o->buckets);
+ IGC_FIX12_PVEC (ss, &o->buckets);
}
MPS_SCAN_END (ss);
return MPS_RES_OK;
@@ -3471,7 +3471,7 @@ finalize_bignum (struct Lisp_Bignum *n)
finalize_font (struct font *font)
{
struct Lisp_Vector *v = (void *) font;
- if (vector_size (v) == FONT_OBJECT_MAX)
+ if (vectorlike_size (v) == FONT_OBJECT_MAX)
{
/* The font driver might sometimes be NULL, e.g. if Emacs was
interrupted before it had time to set it up. */
diff --git a/src/lisp.h b/src/lisp.h
index 315ff89f391..fb4201d1a7d 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -1821,13 +1821,19 @@ XVECTOR (Lisp_Object a)
}
INLINE ptrdiff_t
-ASIZE (Lisp_Object array)
+vector_size (const struct Lisp_Vector *v)
{
- ptrdiff_t size = XVECTOR (array)->header.size;
+ ptrdiff_t size = v->header.size;
eassume (0 <= size);
return size;
}
+INLINE ptrdiff_t
+ASIZE (Lisp_Object array)
+{
+ return vector_size (XVECTOR (array));
+}
+
INLINE ptrdiff_t
gc_asize (Lisp_Object array)
{
@@ -2039,11 +2045,17 @@ bool_vector_set (Lisp_Object a, EMACS_INT i, bool b)
/* Conveniences for dealing with Lisp arrays. */
+INLINE Lisp_Object
+vector_ref (const struct Lisp_Vector *v, ptrdiff_t idx)
+{
+ eassert (0 <= idx && idx < vector_size (v));
+ return v->contents[idx];
+}
+
INLINE Lisp_Object
AREF (Lisp_Object array, ptrdiff_t idx)
{
- eassert (0 <= idx && idx < gc_asize (array));
- return XVECTOR (array)->contents[idx];
+ return vector_ref (XVECTOR (array), idx);
}
INLINE Lisp_Object *
@@ -2053,11 +2065,17 @@ aref_addr (Lisp_Object array, ptrdiff_t idx)
return & XVECTOR (array)->contents[idx];
}
+INLINE void
+vector_set (struct Lisp_Vector *v, ptrdiff_t idx, Lisp_Object val)
+{
+ eassert (0 <= idx && idx < vector_size (v));
+ v->contents[idx] = val;
+}
+
INLINE void
ASET (Lisp_Object array, ptrdiff_t idx, Lisp_Object val)
{
- eassert (0 <= idx && idx < ASIZE (array));
- XVECTOR (array)->contents[idx] = val;
+ vector_set (XVECTOR (array), idx, val);
}
INLINE void
@@ -2482,7 +2500,7 @@ #define DEFSYM(sym, name) /* empty */
/* Array of 2**size_bits values, each being either a (bare) symbol or
the fixnum 0. The symbols for each bucket are chained via
their s.next field. */
- Lisp_Object *buckets;
+ struct Lisp_Vector *buckets;
unsigned size_bits; /* log2(size of buckets vector) */
unsigned count; /* number of symbols in obarray */
@@ -2558,7 +2576,7 @@ obarray_iter_at_end (obarray_iter_t *it)
ptrdiff_t size = obarray_size (it->o);
while (++it->idx < size)
{
- Lisp_Object obj = it->o->buckets[it->idx];
+ Lisp_Object obj = vector_ref (it->o->buckets, it->idx);
if (!BASE_EQ (obj, make_fixnum (0)))
{
it->symbol = XBARE_SYMBOL (obj);
diff --git a/src/lread.c b/src/lread.c
index a248c8f5ed9..8dac71f4c7a 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4903,9 +4903,10 @@ intern_sym (Lisp_Object sym, Lisp_Object obarray, Lisp_Object index)
}
struct Lisp_Obarray *o = XOBARRAY (obarray);
- Lisp_Object *ptr = o->buckets + XFIXNUM (index);
- s->u.s.next = BARE_SYMBOL_P (*ptr) ? XBARE_SYMBOL (*ptr) : NULL;
- *ptr = sym;
+ ptrdiff_t idx = XFIXNUM (index);
+ Lisp_Object entry = vector_ref (o->buckets, idx);
+ s->u.s.next = BARE_SYMBOL_P (entry) ? XBARE_SYMBOL (entry) : NULL;
+ vector_set (o->buckets, idx, sym);
o->count++;
if (o->count > obarray_size (o))
grow_obarray (o);
@@ -5113,12 +5114,17 @@ DEFUN ("unintern", Funintern, Sunintern, 2, 2, 0,
sym->u.s.interned = SYMBOL_UNINTERNED;
ptrdiff_t idx = oblookup_last_bucket_number;
- Lisp_Object *loc = &XOBARRAY (obarray)->buckets[idx];
+ struct Lisp_Vector *buckets = XOBARRAY (obarray)->buckets;
+ Lisp_Object entry = vector_ref (buckets, idx);
- eassert (BARE_SYMBOL_P (*loc));
- struct Lisp_Symbol *prev = XBARE_SYMBOL (*loc);
+ eassert (BARE_SYMBOL_P (entry));
+ struct Lisp_Symbol *prev = XBARE_SYMBOL (entry);
if (sym == prev)
- *loc = sym->u.s.next ? make_lisp_symbol (sym->u.s.next) : make_fixnum (0);
+ {
+ Lisp_Object val
+ = sym->u.s.next ? make_lisp_symbol (sym->u.s.next) : make_fixnum (0);
+ vector_set (buckets, idx, val);
+ }
else
while (1)
{
@@ -5157,7 +5163,7 @@ oblookup (Lisp_Object obarray, register const char *ptr, ptrdiff_t size, ptrdiff
{
struct Lisp_Obarray *o = XOBARRAY (obarray);
ptrdiff_t idx = obarray_index (o, ptr, size_byte);
- Lisp_Object bucket = o->buckets[idx];
+ Lisp_Object bucket = vector_ref (o->buckets, idx);
oblookup_last_bucket_number = idx;
if (!BASE_EQ (bucket, make_fixnum (0)))
@@ -5255,13 +5261,7 @@ make_obarray (unsigned bits)
o->count = 0;
o->size_bits = bits;
ptrdiff_t size = (ptrdiff_t)1 << bits;
-#ifdef HAVE_MPS
- o->buckets = hash_table_alloc_kv (o, size);
-#else
- o->buckets = hash_table_alloc_bytes (size * sizeof *o->buckets);
-#endif
- for (ptrdiff_t i = 0; i < size; i++)
- o->buckets[i] = make_fixnum (0);
+ o->buckets = XVECTOR (make_vector (size, make_fixnum (0)));
return make_lisp_obarray (o);
}
@@ -5277,19 +5277,13 @@ grow_obarray (struct Lisp_Obarray *o)
{
ptrdiff_t old_size = obarray_size (o);
eassert (o->count > old_size);
- Lisp_Object *old_buckets = o->buckets;
+ struct Lisp_Vector *old_buckets = o->buckets;
int new_bits = o->size_bits + 1;
if (new_bits > obarray_max_bits)
error ("Obarray too big");
ptrdiff_t new_size = (ptrdiff_t) 1 << new_bits;
-#ifdef HAVE_MPS
- o->buckets = hash_table_alloc_kv (o, new_size);
-#else
- o->buckets = hash_table_alloc_bytes (new_size * sizeof *o->buckets);
-#endif
- for (ptrdiff_t i = 0; i < new_size; i++)
- o->buckets[i] = make_fixnum (0);
+ o->buckets = XVECTOR (make_vector (new_size, make_fixnum (0)));
o->size_bits = new_bits;
/* Rehash symbols.
@@ -5297,7 +5291,7 @@ grow_obarray (struct Lisp_Obarray *o)
symbol name. Would it be reasonable to store it in the symbol? */
for (ptrdiff_t i = 0; i < old_size; i++)
{
- Lisp_Object obj = old_buckets[i];
+ Lisp_Object obj = vector_ref (old_buckets, i);
if (BARE_SYMBOL_P (obj))
{
struct Lisp_Symbol *s = XBARE_SYMBOL (obj);
@@ -5305,18 +5299,16 @@ grow_obarray (struct Lisp_Obarray *o)
{
Lisp_Object name = s->u.s.name;
ptrdiff_t idx = obarray_index (o, SSDATA (name), SBYTES (name));
- Lisp_Object *loc = o->buckets + idx;
+ Lisp_Object sym = vector_ref (o->buckets, idx);
struct Lisp_Symbol *next = s->u.s.next;
- s->u.s.next = BARE_SYMBOL_P (*loc) ? XBARE_SYMBOL (*loc) : NULL;
- *loc = make_lisp_symbol (s);
+ s->u.s.next = BARE_SYMBOL_P (sym) ? XBARE_SYMBOL (sym) : NULL;
+ vector_set (o->buckets, idx, make_lisp_symbol (s));
if (next == NULL)
break;
s = next;
}
}
}
-
- hash_table_free_kv (o, old_buckets, old_size);
}
DEFUN ("obarray-make", Fobarray_make, Sobarray_make, 0, 1, 0,
@@ -5357,22 +5349,7 @@ DEFUN ("obarray-clear", Fobarray_clear, Sobarray_clear, 1, 1, 0,
to uninterned. It doesn't matter very much. */
int new_bits = obarray_default_bits;
int new_size = (ptrdiff_t)1 << new_bits;
-#ifdef HAVE_MPS
- Lisp_Object *new_buckets = hash_table_alloc_kv (o, new_size);
-#else
- Lisp_Object *new_buckets
- = hash_table_alloc_bytes (new_size * sizeof *new_buckets);
-#endif
- for (ptrdiff_t i = 0; i < new_size; i++)
- new_buckets[i] = make_fixnum (0);
-
-#ifdef HAVE_MPS
- hash_table_free_kv (o, o->buckets, -1 /* ignored */);
-#else
- int old_size = obarray_size (o);
- hash_table_free_bytes (o->buckets, old_size * sizeof *o->buckets);
-#endif
- o->buckets = new_buckets;
+ o->buckets = XVECTOR (make_vector (new_size, make_fixnum (0)));
o->size_bits = new_bits;
o->count = 0;
@@ -5418,7 +5395,7 @@ DEFUN ("internal--obarray-buckets",
for (ptrdiff_t i = 0; i < size; i++)
{
Lisp_Object bucket = Qnil;
- Lisp_Object sym = XOBARRAY (obarray)->buckets[i];
+ Lisp_Object sym = vector_ref (XOBARRAY (obarray)->buckets, i);
if (BARE_SYMBOL_P (sym))
while (1)
{
diff --git a/src/pdumper.c b/src/pdumper.c
index d73a0704e20..e2e491ef46e 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2857,16 +2857,10 @@ dump_weak_hash_table (struct dump_context *ctx, Lisp_Object object)
}
#endif
-static dump_off
-dump_obarray_buckets (struct dump_context *ctx, const struct Lisp_Obarray *o)
-{
- return dump_hash_vec (ctx, o->buckets, obarray_size (o));
-}
-
static dump_off
dump_obarray (struct dump_context *ctx, Lisp_Object object)
{
-#if CHECK_STRUCTS && !defined HASH_Lisp_Obarray_29CFFD1B74
+#if CHECK_STRUCTS && !defined HASH_Lisp_Obarray_3BA8AFA3DB
# error "Lisp_Obarray changed. See CHECK_STRUCTS comment in config.h."
#endif
const struct Lisp_Obarray *in_oa = XOBARRAY (object);
@@ -2877,12 +2871,9 @@ dump_obarray (struct dump_context *ctx, Lisp_Object object)
dump_pseudovector_lisp_fields (ctx, &out->header, &oa->header);
DUMP_FIELD_COPY (out, oa, count);
DUMP_FIELD_COPY (out, oa, size_bits);
- dump_field_fixup_later (ctx, out, oa, &oa->buckets);
+ dump_field_lv_rawptr (ctx, out, oa, &oa->buckets, Lisp_Vectorlike,
+ WEIGHT_NORMAL);
dump_off offset = finish_dump_pvec (ctx, &out->header);
- dump_remember_fixup_ptr_raw
- (ctx,
- offset + dump_offsetof (struct Lisp_Obarray, buckets),
- dump_obarray_buckets (ctx, oa));
return offset;
}
--
2.39.5
--=-=-=--
Helmut Eller <eller.helmut@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#78620; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.