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: dangling markers Date: Sun, 30 Jun 2024 13:02:55 +0200 Message-ID: References: <87v81u85hv.fsf@localhost> <86bk3jirx7.fsf@gnu.org> <868qynipph.fsf@gnu.org> <87wmm75xze.fsf@localhost> <7YYJyDLCuZhtkTAT_ry6S14y4KoAJtsV_2Ui8Dsy37afuN1zucoO6VPh6YAvKQCs-0OUP3-rTFogtJBLrv2wiZ9rq6lacV-p_M1qsSSgKOk=@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="21200"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Ihor Radchenko , Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org, eller.helmut@gmail.com To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 13:03:47 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 1sNsLS-0005Ic-O4 for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 13:03:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNsKl-0001lo-7i; Sun, 30 Jun 2024 07:03:03 -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 1sNsKi-0001lG-0s for emacs-devel@gnu.org; Sun, 30 Jun 2024 07:03:01 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNsKg-0007qD-Ab; Sun, 30 Jun 2024 07:02:59 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-362b32fbb3bso1276604f8f.2; Sun, 30 Jun 2024 04:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719745376; x=1720350176; 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=XF8feuYzUs0Drf3hRkPb+hAhXlwozSL4fN2ou/O+tTc=; b=GygsMCwjUC4k2A/3GQDoy02nb4QjaYDHl7vTx8vqw0G6VAmpT01SzzPvKK7OhL9awh ym1B0bblUiMYunan5d3Rb14VTlkPCy5S8SsVEwzYp7w5TKuO4Yel6Nm26XkjxE+4dP49 DDOoqp9WTIn8ticGNty8tAYdago3lDNwFWhHUDFrYa+7pBvXtS/7VSQcjErX/f1qhq8V Cid1Vu4U4okzctj+4tFxlYxPxRx3VZrAFbximYyxrU2f7VnhWVwSjtUMgurUFvjfu0jf padD5KcvDJJt/y9Om2X/S1kt8V2zTwmZCkWbT6BJ9JlV3w6nKFTu71pNAkt0MZ4G4SZM p/Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719745376; x=1720350176; 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=XF8feuYzUs0Drf3hRkPb+hAhXlwozSL4fN2ou/O+tTc=; b=Ogkk6ARgQi1YF7F/3oGciWAD0/TXVdlCTA44Lz1dIrmx4ibGacOiPzpKPwKmrfzUI7 Au8jQm78nItT+nR282Fjd2VJXB/bFPhwn0OK8cuIIXIeUDQAmf7NsBFz9KRPap+MPyx8 BN+Kee7kxKSNd511QcNfBUP215zpaFfELMtAhEm19E0QrJHWvJZ/4vUT3fKi87/riucj IXSiBpXhrAEW2MKWfy4XQbl/W9sjHC/+/zRpVh5pTPDD+BCfVHSNtKYWT1jtZabJJ13I 4lm/6lOvhhkPj7HM5sSM2P4ztQY1/ePnWUupIwXIoztW9AYaiAI7EulvDvBf9ghmIYrV +6Pw== X-Forwarded-Encrypted: i=1; AJvYcCWyu5MN1E6+ffly4dsrzqFrxjmTZU3Uo79m1K4wR6Ig6lD0T8PPiMNhBCOnj3ohVkreDkTXvS7SRrnQNci5Mm6WTPXWx0gNkWg8w7pFEF8+J4A= X-Gm-Message-State: AOJu0Yw0QCr7Ar18j1u6SdqrJV1ZXWSZF0y97aLwa4qBwq7ZOAlHaF11 Jcnh1pQ+45tYq/gVWY1tr0F+wMc/k/yMU1ShkDB14iNPfm6peVu0nFrNhg== X-Google-Smtp-Source: AGHT+IHdb0CnzS2GZTY5PcaVeCxleCskO8AYpRY0WBdzX6A2kAIhSnz02boSd6oNhv9IEGhQJxN9cw== X-Received: by 2002:a5d:5f56:0:b0:366:e801:3177 with SMTP id ffacd0b85a97d-367756992e8mr1971571f8f.13.1719745376355; Sun, 30 Jun 2024 04:02:56 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36a45.dip0.t-ipconnect.de. [217.227.106.69]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3675a0fb950sm7130630f8f.83.2024.06.30.04.02.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jun 2024 04:02:55 -0700 (PDT) In-Reply-To: <7YYJyDLCuZhtkTAT_ry6S14y4KoAJtsV_2Ui8Dsy37afuN1zucoO6VPh6YAvKQCs-0OUP3-rTFogtJBLrv2wiZ9rq6lacV-p_M1qsSSgKOk=@protonmail.com> (Pip Cet's message of "Sun, 30 Jun 2024 09:51:48 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=gerd.moellmann@gmail.com; helo=mail-wr1-x434.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:320943 Archived-At: Pip Cet writes: > I checked in the MPS source code (which, I understand, you don't want > to modify), and the limit appears to be something that can be raised > easily... Interesting to hear! (I don't even want to read MPS, only lots of uninteresting details... :-)). >> > And since we can't resize objects that may be pinned by ambiguous >> > references, well, the weak hash table implementation would look quite >> > different from the strong hash tables we have). > >> If we make-hash-table with weak keys and/or values, allocate the >> Lisp_Hash_Table from the AWL pool using the weak_strong allocation >> point. If neither keys nor values are weak, allocate the hash table from >> the default pool. > >> Allocate the key and the value vector according to the hash table's >> weakness either from the strong or weak allocation point, or from the >> default pool if the table isn't weak at all. (I've split the >> key_and_value vector already in two, but you probably noticed that >> already.) >> >> Dependent object of the key and value vectors could be the hash table >> itself. > > Then we couldn't modify the value vector when the key gets splatted, > or vice versa, so the table wouldn't be properly weak. True. I forgot to mention an important thing: When something is splat, set flag(s) in the dependent hash table indicating that something must be done because of that splatting. In gethash and so, check the flag and do what's necessary. (I did something similar for the weak hash tables in CMUCL, and it wasn't entirely bad. And weak tables should be rare.) > My understanding is we must allocate all strongly-referencing objects > together in one object, all weakly-referencing objects together in > another one, and make them depend on each other. The first 2 points I think are true, and are the reason I split the 1 vector in master containing both keys and values into two in igc, so that keys and values can be weak or not, as necessary. The 3rd thing you wrote I'm not sure. My understanding is that specifying a dependent object simply means that MPS makes it accessible while scanning the depending object. I don't think MPS does anything to the dependent object by itself. Hence the idea to make the hash table the dependent object so that one at least can "notify" it that something has happened, so that it can modify index and next vectors. > And that means making the pseudovec a mere tuple of pointers to the > strong and weak parts, because the conglomerate objects might need to > be resized... I'm afraid I couldn't follow. Could you please explain?