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:38:18 +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="1469"; 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:39:22 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 1sOuaH-00005C-Uj for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jul 2024 09:39:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOuZN-0002AC-N0; Wed, 03 Jul 2024 03:38:25 -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 1sOuZL-00029d-Lz for emacs-devel@gnu.org; Wed, 03 Jul 2024 03:38:24 -0400 Original-Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOuZJ-0003rD-S9; Wed, 03 Jul 2024 03:38:23 -0400 Original-Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-58b3fee65d8so2258511a12.3; Wed, 03 Jul 2024 00:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719992299; x=1720597099; 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=PVoZX81mcsnAAiFX9b2nhPh/2ffYEXd67LNvhri9ZqM=; b=DoO7yCQ+hoS7v3j/LAbY3PrY3RYkIK3lIgmYvAWpwq5QNh8lw7T+V9Itart4jYPVd2 mQSS1Kr4IzMhr2OEgYih4zIQ0ErmZARhCzbz+o7af8v+NNHgIf4ENehmcHmWktIvuMOv 9p7nhf4RcS203VNf/yS2I6+FMgi+vD7jcAsSd45OsovqcIGU4jbRjE6RIX5nz/tFLCNZ 9CYYzjiMXuwH0AWFFiOcCFofc+yN5ewckgiAe2R/U6OvhGwT/0Spc4mHfAZS1nmKgGw8 D3jb+abQBQy72xJla4xsy2uhqCGruDsLph1bjja9yTJnwoAWx5FguR2vXfnZE1vP7+Hl 567w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719992299; x=1720597099; 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=PVoZX81mcsnAAiFX9b2nhPh/2ffYEXd67LNvhri9ZqM=; b=OMEXcHXJnTqaIcG/0ba8DrhjIfP/szwWAcKy9Sn3nUCWykWMZjkiabN95CGOfHk+Aq 7XYDBTaGfJ6vQMJcRtTOuIr42bIe2GlAPpPg7ek2pL18Puafqp/I1VNyDGiygpItlc6/ XvkKKlzuSAs/+OnQ8kZvgzAMs9BA2PD4Ug+HAQgrNDB9OcqVhZJ4a606vsTXBVGerpIb lsMMtOXi29HfWFSzoUEs6PiHSyGaDnd/O/j+8VBc8E29yqJTmfaYoA14ASV7KlPW+tsi fzDurpjQc719E93D07dWYTOZh65UZFocdHJmZnbkW3pUUYomLvLe4n3N+piiSaJ49dyx vyiQ== X-Forwarded-Encrypted: i=1; AJvYcCXre0liIVTipsqlqnWEL1Ex2xDSp/G+UsR1r4j+OlspXUMqfpM6XVBFnzphcVYO6toSmb5VcFFjXO6X9+4gWQOP+oUK3IwOipZNPT1ABLr8nhE= X-Gm-Message-State: AOJu0Yy2zRrhyxU2ZYPb2nSTzpV6vXpBr4lEDzDn2BNzi7wduHudr8e3 AqZNhe7xW4Oe3eS9xgQJpIznBSW/0lOysvAE31f+4T4DyjchIV1eSdQ3ZA== X-Google-Smtp-Source: AGHT+IGF5E0iNTJ+K+UEsaxO5VsJS6z4dFKXvsGh5g5Acx7c3r5P28daEvkqzDyWWRS07XfTg26xtQ== X-Received: by 2002:aa7:d591:0:b0:58d:eca:b9bf with SMTP id 4fb4d7f45d1cf-58d0ecaba83mr297734a12.37.1719992299453; Wed, 03 Jul 2024 00:38:19 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e362dd.dip0.t-ipconnect.de. [217.227.98.221]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-58614d50464sm6591156a12.69.2024.07.03.00.38.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jul 2024 00:38:19 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Wed, 03 Jul 2024 07:25:20 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52a; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52a.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:321236 Archived-At: Pip Cet writes: > 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), IANAL either, but I think one could: This is the license under which the Memory Pool System Kit is made available by Ravenbrook Limited. This license is generally known as the `BSD 2-clause license`_. It is `GPL compatible`_ and `OSI approved`_. > but I'd strongly prefer to discuss that only if and when scratch/igc > is merged. Everything else is premature. Ok. >> 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 finalization message. > > This process is known as resurrection and in some finalization systems > requires special handling, but in the MPS this just is just the usual > result of the rule that strong references keep objects alive. Thanks. > 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. Ok, maybe if we let it ripe a bit, an idea emerges. >> > > 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. > > git merge scratch/no-purespace :-) Long done, in a repos lightyears away :-).