From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: MPS: weak hash tables Date: Wed, 03 Jul 2024 07:25:20 +0000 Message-ID: References: <2syUQ04IbTWqDJjMfKSrtzWMWmFGq1GIOwSxv_r6BEyNDtk7ADADKjZk-90g9tSS9SKWppkiq6_zihUtsoE1spiopaOI6-v9inQrGxwMyCs=@protonmail.com> <87o77gvxz3.fsf@gmail.com> <1VNw6cPSIpKfxNRqQBpVleX2BDbQuUqwLQzo-C8N-_PRvNNLG3BnhbcWpUJkiJYnOogBvqRTcLApebjqdZel7CgXVx9T0CnPn6_go_AugDA=@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="35467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Helmut Eller , Eli Zaretskii , Emacs Devel To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 03 12:53:13 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 1sOxbs-0008rs-J7 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jul 2024 12:53:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOxbF-0002bi-Dc; Wed, 03 Jul 2024 06:52:33 -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 1sOuMz-0008Qd-4t for emacs-devel@gnu.org; Wed, 03 Jul 2024 03:25:37 -0400 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOuMr-0002n1-Fy; Wed, 03 Jul 2024 03:25:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1719991524; x=1720250724; bh=hdZS0kXKyFxyEPxM5D8ZtTCNK9fezd7L08SkJTlwIrQ=; 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; b=SGj1bI0E40oPQ6wk7rNJcxbQPzRTazUaOLi7coxzkalm0zoCx7KayTjuMNsEynvvf FXBsIXexYgRfTDJyoagQikKE2A9rMfuxzpa9jIJeWtkMc+0m8JJ1TN0QmnCmRxnm9p QerY88Q6cizLzGEuLY2QuTkM1P5mtg83cRLb8OfWOgQH0KI1Ig8hSzmsZ5+Tod6aeY BRgU+99E0coTWghh91wjPAW9/jVB3kpiBZBESZoCBb1NzsD3zq5EW98Jusv0wmUWh8 Qpwc68UF/QU2yuIQsZNPoYvDaEjsgnp9eGhicVlg+2xUI/Dajt2YqDRWOBLbWdfHiz dhqbpRzrNcojg== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b6548537255a2758bc8fa00b1b25a75fd1145064 Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 03 Jul 2024 06:52:28 -0400 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:321243 Archived-At: On Wednesday, July 3rd, 2024 at 07:04, Gerd M=C3=B6llmann wrote: > Pip Cet pipcet@protonmail.com writes: >=20 > > > I can understand that Ravenbrook documents these restrictions, for > > > future (payed) developments and so on, but, you know... implementing > > > them gets pretty ugly pretty quickly. (And I wonder if the emulation > > > brings enough to warrant the effort.) > >=20 > > Frankly, I wonder how they'd feel about a patch to make emulation > > optional on all architectures, so the restrictions would be optional > > as well. I'm playing with a qemu IA32 environment, but haven't been > > able to trigger the emulation code yet (even on IA32, only some very > > simple instructions are emulated). >=20 > Right, they say themselves that only simple instructions are handled. >=20 > Hm, one could try. Maybe you could submit an issue for that on their > github project? The only "problem" is see is that they are not very > responsive. Not that they aren't very friendly and so on, it just takes > them some time to react, and sometimes they don't. I believe we should leave our options open as far as modifying MPS goes: my= understanding is we could, if we really wanted to (but IANAL), but I'd str= ongly prefer to discuss that only if and when scratch/igc is merged. Everyt= hing else is premature. > (When I sent a mail to info@ravenbrook.com some months ago to make them > aware that something in Emacs is going on wrt MPS and to thank them for > MPS (couldn't find another address), someone told me that Ravenbrook > isn't that large anymore, or something like that. My guess is that they > are getting old, too. I think MPS had its first release, commercial, > in 1997.) >=20 > > I've run into another issue: finalization. MPS's take on that is > > rather unusual, in that an object can be "finalized" while weak > > references to it still exist (and destruction can be vetoed by the > > finalization code creating a new strong reference to it, IIUC). The > > upshot of this is that this code: > >=20 > > (setq bignum (1+ most-positive-fixnum)) > > (setq table (make-hash-table :test 'eq :weakness 'key)) > > (puthash bignum t table) > > table > > (setq bignum nil) > > (setq values nil) > > (igc--collect) > > table > >=20 > > produces a table with a nonsensical/random bignum as key, because the > > memory has been freed and reused for something else. > >=20 > > I have a patch here which "splats" finalized pvecs so they become > > PVEC_FREE, ignores such objects during iteration, and gets rid of the > > "count" element, instead counting the elements for (hash-table-count > > weak-table). I'll install it after some more testing, unless a better > > solution occurs to someone. >=20 > I have a vague memory that the docs say somewhere that a finalizer can > decline finalization by creating a strong reference, but I can't find it > anymore, as usual. Could we use that somehow, maybe? https://memory-pool-system.readthedocs.io/en/latest/topic/finalization.html= #topic-finalization: The client program may choose to keep the finalized block alive by keeping = a strong reference to the finalized object after discarding the finalizatio= n message. This process is known as resurrection and in some finalization systems requ= ires special handling, but in the MPS this just is just the usual result of= the rule that strong references keep objects alive. We could use that for key-or-value hash tables, but those aren't really my = priority. I don't see a way to use it for the more usual weak hash tables, but maybe = I'm missing something. > > > It would be nice if the ugliness could be encapsulated so that one > > > doesn't have to see it all the time, as far as that it possible in C > > > :-). Or conditionalized, maybe, because with Helmut's idea (which I f= ind > > > the right one), we're using and additional word for weak references. > >=20 > > How hard would it be to "just" add struct igc_headers to the remaining > > non-headered objects? I don't really want to reopen the "get rid of > > pure space" discussion again, but that's probably the hard part? >=20 > I'd say it's not hard to add the headers to pure space. (Let me briefly > sprinkle in that pure space should die :-)). There is a function > pure_alloc that is used to allocate objects in pure space, AFAIK. git merge scratch/no-purespace :-) > For lispsym, main_threads, and subrs (DEFUN etc.), one would have to > create static structs with an igc_header member. That's probably also > not really difficult but could result in a lot of work. >=20 > And of course igc_header would have to be made visible everywhere, and > so on. A lot of work... You're right. I think Helmut's idea is great, actually, and I don't mind th= e extra cost for now. Large weak hash tables are expensive, and memory is t= he least of that problem. Pip