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 06:41:03 +0200 Message-ID: References: <87v81u85hv.fsf@localhost> <86ed8fiug3.fsf@gnu.org> <86bk3jirx7.fsf@gnu.org> <868qynipph.fsf@gnu.org> <87wmm75xze.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34198"; 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 06:41:32 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 1sNmNY-0008ld-N3 for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 06:41:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNmNE-0003N1-NU; Sun, 30 Jun 2024 00:41:13 -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 1sNmNC-0003MV-CH for emacs-devel@gnu.org; Sun, 30 Jun 2024 00:41:10 -0400 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNmN8-00054A-Uw; Sun, 30 Jun 2024 00:41:08 -0400 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-57d1d614049so2335794a12.1; Sat, 29 Jun 2024 21:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719722465; x=1720327265; 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=sMD5SI0b5q3dW4/sCmZQUq1lHkcDrWFBMYNgJ88mNjU=; b=hzQBFGOAzA4S9F8jl3nO0VGIu9B91JJBRUg9YuFIZjNXFspRPcSd4+9TgnDHjiJkiE 2zXRy10nQU2S8XHf+aJWerNEVZZdKIktbMQ/2VezdZ0pHo43GgZiAzKOeMe+oxKrK4zD nalpmivtQ2fMTK/7RmtYBYTtd+6nrE/FpqG+b6QrYBQ7ued1GslE4ZipB3LwvIBTKI+B znXZ3kYCvGe16f+fuy8+jxTI4MWlKQE0zFqIDyMj9F/8Cf8h3B2d/Qs3YPlPEfgpBkLV 0lT0ZbIIqt2AUhqoRfobJuOpSnGPrRz8xmR32SyHqwZDkB1w0cnW4uvDv7/GWu/9xlE8 rN/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719722465; x=1720327265; 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=sMD5SI0b5q3dW4/sCmZQUq1lHkcDrWFBMYNgJ88mNjU=; b=bGYceLwvxLN7WLmAiKikT5J14lmBs/oK5/jzlJcAyKG/2ZSiBAHhiuZOSTeKavKcFC ycw380scLsEqzL++BYGxzTyjOihsW0S0s9+ClvwQfbqZb4EZ4+K2E0Jo4UP8ko9SEmss 3jMsuhwBR6P7L979DqA8VMUAAREXDHBAvu7CCWDsttbk0OUZpPh4Pmxw5NDCg/BkrWti tTlxRWtdD8xVbMiMmOK2UUkvpdxaBEZ9QUjhrQvZYeusEbFP4KZE5GmFZLtecwkXK++A iIm6HhNcTh4wY8xWDyVJ9o9NL0a7HnKQhqE4o/9NhqeX+4jPQHFusdHnLA/BK09PE24s jrzA== X-Forwarded-Encrypted: i=1; AJvYcCVsoeZN1hcQl7pyuCONrkZwT87f4t6S8mn9hpaBPoSWQlCOYu+TC+WVTtMfxn1B+NM7ZplglrN2tfCqzhOQtYVbN0aVgU7WW3azDJ1uEuzTYTQ= X-Gm-Message-State: AOJu0YxSL9gQKTAin5Jc739+0WwQBQoMegNXseHcyNy2mZSQ0UdH377n qti52Yo8XlqCcLcWOVhKEi8oJh0xNl7Fded0eZcFAeG1noKI/raPJIKMUw== X-Google-Smtp-Source: AGHT+IGdKBWoGjpGk8nlmOLEi3YrK7uEIIcNrTXNf4nnsplGvMcO7z9YDVEWRdiNpo/tMkkZot+odQ== X-Received: by 2002:a05:6402:2114:b0:57d:2138:d114 with SMTP id 4fb4d7f45d1cf-5879f3ac6b5mr1990253a12.15.1719722464687; Sat, 29 Jun 2024 21:41:04 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36a45.dip0.t-ipconnect.de. [217.227.106.69]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-58614d50464sm2928431a12.69.2024.06.29.21.41.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Jun 2024 21:41:04 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Sat, 29 Jun 2024 22:33:23 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52b.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:320907 Archived-At: Pip Cet writes: > (Implementing weak hash tables with MPS seems quite difficult, though: > you can have only one "dependent object" with strong references per > object with weak references, Yes, the one dependent object is somewhat limiting. I though yesterday that using something like a weak doubly-linked list could be the solution for the markers, but that would require 2 dependent objects, next and prev. Anyway. > and it cannot be in a moving pool. Right. > 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). I thought that, very roughly, the following might be doable: 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. > Of course, Stefan's plan is even better :-) > > Also, why does igc-info not walk the weak pool? Isn't that where the > problematic markers are? Lazyness, it should walk all pools we have :-). I have that as a todo. Time to do it, I guess. The weak pool currently only contains the weak vectors for markers, the markers themselves live in the default pool.