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: Wed, 03 Jul 2024 09:04:20 +0200 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18948"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , Eli Zaretskii , Emacs Devel To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 03 09:05:20 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 1sOu3L-0004Wp-MB for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jul 2024 09:05:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOu2W-0002Yk-3o; Wed, 03 Jul 2024 03:04:28 -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 1sOu2U-0002YL-Nl for emacs-devel@gnu.org; Wed, 03 Jul 2024 03:04:26 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOu2S-00079K-FU; Wed, 03 Jul 2024 03:04:26 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3678aa359b7so153273f8f.1; Wed, 03 Jul 2024 00:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719990262; x=1720595062; darn=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=Ew3NpMYjkU3zR6FebPky21Hq42iZzxbne2fe7bMN16E=; b=B6XRa1C2AsZHHrDVap6I/vO0GXx+DnNUcN47ewcgzYE9OZfzd06HjfhghZAQFkKqgN TyxVWUgdwaYKGDSG0GgXqXiMwzwoEV/dy1BaBGXGC6qD0pJsj6OZjJWnc9pB2ZHMGy3A g1g7qvl0HHegtoXOrT6jGS7v3b3FkAHphrpv5zAvwvvZTBojhud39RZ4+3mUaxLjyj33 m/ELEJa7UErwajs/bMN7roX9cVoG3ySgXGqTh0Kco7GP1ilKt1tmNTR40ynGGTJxOnQp lE3gPSvFjctZ7CfnmphhfqygauoznNa08u6CIVKwrfLnJRA1MGKABJuPyYJvVmHhFBfO xzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719990262; x=1720595062; 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=Ew3NpMYjkU3zR6FebPky21Hq42iZzxbne2fe7bMN16E=; b=SF390pZ9eevZbKunmcRp43jEl5xyKi+5eJt31dH+r2zskPuv0kEOjAu8iThp0nRnOy HzTma8Ei+IAxRikqD1lyCsOPtSVEQxjF4SUbAkoFCIu4CHalR9N1erZmPNxOKFHo3quL DQSwp2yJbb/Tbs+DxtPT16sYGT47aN+HjAgKEEmlsZ/sIJ7cF7XY3lBBryhJSV6Z9/QY MHfwH3DXctt7TTyWW8AfJC+RBWCrr/T4+btK3soA/NbCK3bgMd243uqL28zVncOGIBXY 8CNazPD0dqK6p81QlD3pVLgSNamdKU7oSdbo9FWM3MV8bqEUmEzqyCjI5ob/mcS1wnQt nm0A== X-Forwarded-Encrypted: i=1; AJvYcCWiM5P0uxNwlt0U3jFai2sTWKp32n1yQQWtoB+AWEq3q16/LA8ouz0ceZtddWVgUctxA0mIuXnG5xTZexBxHFRtsL+3RgSqLwqPbAmlMqYgHlA= X-Gm-Message-State: AOJu0YydIFsqznpgTRlYZhUrzyzv3r2WPSamLID8Bia1QTQGroiuAoKo k7cAkHPHqM01F4ABTuBVj1lIZ2mx2F0YE4X6q5aylsd0H3ywe3kcDHHCNQ== X-Google-Smtp-Source: AGHT+IGdg6icZexwY+qlH3N4wecbMEM5zUbysEWtkTLG9IU5vmeKzzzyT2eCC9hxp8XbzVkj/WWZhQ== X-Received: by 2002:a5d:6081:0:b0:367:8fe2:7d8b with SMTP id ffacd0b85a97d-367947f8f1amr637585f8f.31.1719990261784; Wed, 03 Jul 2024 00:04:21 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e362dd.dip0.t-ipconnect.de. [217.227.98.221]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4256b0971d2sm224614025e9.31.2024.07.03.00.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jul 2024 00:04:21 -0700 (PDT) In-Reply-To: <1VNw6cPSIpKfxNRqQBpVleX2BDbQuUqwLQzo-C8N-_PRvNNLG3BnhbcWpUJkiJYnOogBvqRTcLApebjqdZel7CgXVx9T0CnPn6_go_AugDA=@protonmail.com> (Pip Cet's message of "Wed, 03 Jul 2024 06:33:23 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=gerd.moellmann@gmail.com; helo=mail-wr1-x42a.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:321233 Archived-At: Pip Cet writes: >> 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.) > > 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). Right, they say themselves that only simple instructions are handled. 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. (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.) > 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: > > (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 > > produces a table with a nonsensical/random bignum as key, because the > memory has been freed and reused for something else. > > 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. 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? > >> 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 find >> the right one), we're using and additional word for weak references. > > 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? 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. 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. And of course igc_header would have to be made visible everywhere, and so on. A lot of work...