From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: weak hash tables Date: Tue, 02 Jul 2024 08:55:11 +0200 Message-ID: References: <2syUQ04IbTWqDJjMfKSrtzWMWmFGq1GIOwSxv_r6BEyNDtk7ADADKjZk-90g9tSS9SKWppkiq6_zihUtsoE1spiopaOI6-v9inQrGxwMyCs=@protonmail.com> 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="3935"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Helmut Eller , Emacs Devel To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 02 08:56:23 2024 Return-path: Envelope-to: ged-emacs-devel@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 1sOXR7-0000hA-U9 for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 08:56:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOXQE-0000Gv-Ji; Tue, 02 Jul 2024 02:55:26 -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 1sOXQ6-0000G0-Ef for emacs-devel@gnu.org; Tue, 02 Jul 2024 02:55:18 -0400 Original-Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOXQ4-0001kn-JN; Tue, 02 Jul 2024 02:55:18 -0400 Original-Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-57d06101d76so1228020a12.3; Mon, 01 Jul 2024 23:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719903313; x=1720508113; darn=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=Su98fqTU+hTgcjlSqdAOP3MX6rP+7JWUbSB5H9AaTek=; b=ZWR7ky3kjokTqk0gCkziKzj0zMTz8HnIXe2VLl3U15yInNgS9ocHyno0IzbreBs4iq p+fA+0IqlUXJOwWf56EirYx1nS0D1ZducYOaBw1LZQ0pf4BKwOgwOpBJ6Sh7YyHzWPjD 1T72k15n42ew6LU/BvkiP22qklIHRFnoo3n+yxuX3pf5bPer8TFzebAinO+FvIe7SxEC 1rgVD3NklWKzKQdjV0BIXR0aNlLy6kg8Ae4DumR8x1NRDbyPK1QzLXr/x/1KdiqAc7vQ THKYaXtgsWr5a9tVoggoLUHVc5aWzGPh0ssG6VOXlU6wn7V1vM48FAZrkO6CmAzrTtyW xQ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719903313; x=1720508113; 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=Su98fqTU+hTgcjlSqdAOP3MX6rP+7JWUbSB5H9AaTek=; b=vsoRaGsyef6qsTw5sL3f4oeYsxCyGHzR9DOE9rWGnTTMFMdTHw2WzItHzahFjnJlj4 Y49TWl0MkDok8yTcbUOr1CXrOBkeOKHwsimAER5G7CXzM+vhEYc03KrbjK0c3B2okYal TcnTO+NZJh98h6m+cpYNbeIumeeb+w9K+Rorx+Zhi1CYOlYT+BkPAorJAq1qh7y/Irng zA6jeUKETwl/ZyKR5Ugcu1RTWYus/vDHUOa3bqTxxkbckTzoMLIBelbpvxhmGx9J7+Ty U4MfXiL5GPJsxvYupFaB9QyPh0vaFRZ3W8sIAn96wgpiK8O+Y5jCG1EcYBVw9jgjGl0w o95A== X-Forwarded-Encrypted: i=1; AJvYcCWIH8fzSiNQfLmtZREp2fk7NWO8PuWOlZ6qdtUoYbE2wBVRa7vH6nPYK1bqj4Pa97XBcJzJjoicfeABrEJJwj1TuYxx X-Gm-Message-State: AOJu0YzNRad5feMvtmAYC4BUtKdfzMkCDpuj/xzXeuyl54GMJ4Xn2QG8 Fe6TVNDeYGRFaTg/GTw19uG6NE5yISufP2SeGjMb6by45mLgVcC3HeShUw== X-Google-Smtp-Source: AGHT+IHwgJsZw8zLbfIzaFJlvy0z2KglSGtC53Kq30gsneoXyyy4899Z6IZpbi33GH7Mr+LLGyDuLg== X-Received: by 2002:a05:6402:1910:b0:57d:619:7721 with SMTP id 4fb4d7f45d1cf-5879f982feemr5343027a12.21.1719903312848; Mon, 01 Jul 2024 23:55:12 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36129.dip0.t-ipconnect.de. [217.227.97.41]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-58614f3d4c4sm5300070a12.87.2024.07.01.23.55.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jul 2024 23:55:12 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Tue, 02 Jul 2024 06:23:45 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, 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=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321099 Archived-At: Pip Cet writes: > On Tuesday, July 2nd, 2024 at 05:47, Gerd M=C3=B6llmann wrote: >> Pip Cet pipcet@protonmail.com writes: >>=20 >> > Also, any opinions on :weakness 'key-or-value? Can we just not support= it and use strong hash tables instead? >>=20 >>=20 >> So, after some more reading, I think I have an opinion. Let me read what >> it is :-) >>=20 >> The design supports 1 vector of weak references, and 1 vector of >> strong references. So either keys or values can be weak but not both. > > Why not? I may be missing something obvious, but the scan method is > allowed to modify the scanned object, right? We're doing that in the > weak-key case anyway. I may be missing something as well, as usual :-). And yes, we have exclusive access to the object while it is being scanned. > So what I'm currently doing is creating a single vector containing all > keys, then all values, for key-and-value hash tables. If the key gets > splatted, the value gets splatted right away and everything works as > it should. If the value gets splatted, we've already decided to keep > alive the key, but that's okay as it's only a weak reference. My understanding so far is that the strong part is always allocated with rank strong, right? The strong part contains one array of references, the entries, which are therefore also strong. The pointers to the entries for key/value are set up to refer to the entries arrays of either the strong part or the weak part, as needed. So my understanding is that one of them is always strong and other weak. The W predicate can then only be implemented in one of them. >> In Emacs itself, I see from git grep that :weakness key, value, and t >> are being used, where t means key-and-value. Haven't checked for which >> use cases t is used, though. > > What surprised me is that there are plenty of hash tables that are > both weak and use equal as a predicate. That doesn't make much sense > to me... Hm, maybe they are value weak? Key-weak would make no sense, I think, indeed. > >> Anyway, we're better off than before :-). > > On 64-bit systems. 32-bit systems are still broken, I'm afraid, and > while my patch fixes the crash I've seen on i386 Debian, Eli's crash > looked very different and may not be fixed by it. >From my POV, it's not a deal breaker if 32-bit systems don't work with igc, They still have the old GC, and 32-bit systems are kind of obsolete even Intel says and so on. It would be nice if we could that working of course. > Also, there's the whole caution thing about weak objects containing > only unaligned words or words pointing directly to a base object, > which is only relevant on Unix/i386, IIRC. (MPS emulates instructions > to simulate fine-grained barriers, which is a really cool idea; I'd > still like an option to turn it off though...). That would mean we > have to replace Lisp_Objects and use the ptr member of our union (and > that's the reason I'm using fixnums rather than plain integers for the > hash). Yeah, that's another point I forgot about. The trickery MPS does on Windows and Linux with 32-bits. The consequences of which are another very good reason to declare 32-bit systems as not supproted, from my POV. > Anyway, thanks a lot, so far. Sorry I'm being dense about the > key-and-value thing. Nicht daf=C3=BCr (something meaning with pleasure :-)).