From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Collecting markers with MPS Date: Wed, 24 Apr 2024 17:03:10 +0200 Message-ID: <87wmomiz0x.fsf@gmail.com> References: <87cyqfjk6n.fsf@gmail.com> <86sezb2oj2.fsf@gnu.org> <874jbrjg04.fsf@gmail.com> <86o79z2h7y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40504"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 24 17:03:53 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 1rzeA4-000AJl-Sq for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Apr 2024 17:03:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rze9V-0003tp-VS; Wed, 24 Apr 2024 11:03:18 -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 1rze9U-0003tV-Kd for emacs-devel@gnu.org; Wed, 24 Apr 2024 11:03:16 -0400 Original-Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rze9S-0008Oo-Os; Wed, 24 Apr 2024 11:03:16 -0400 Original-Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a5200afe39eso763105666b.1; Wed, 24 Apr 2024 08:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713970992; x=1714575792; 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=zilSaPT1gKQDHuLZg2mJlrz6eK5WFxhx0Ap7kd/9iC8=; b=X3CrNjyKyOuriLOV+ZIAT7DjdUZwnw2XQkcy3Lzn2PQPCl6B1oIX5qsEGZowyuFIQn qlb7lEnguSj2IUfRRMnHXNiin6r15PeyM7QTRJDjcmi3EoCRBdytqIhkHd1rSupwtEH5 1iTy+K4gvrH/gqVIg4A0Id08RMpGXkZ9Ns62IyVBNfZK2W2h3WneqyHHxrRmjo3aXfLQ +yZUVCFSG9E+j9meG3q858GX3oGycpGYLLYURRra6011sikuJjIFh0Mr1LCZ52u2P3uy jLj16yd1fJhEq4pIp9H1W/oRKEpcesHmyph3cF7+37uj2Z7j0JuAgy4exTB4M2uJMuOC vb8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713970992; x=1714575792; 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=zilSaPT1gKQDHuLZg2mJlrz6eK5WFxhx0Ap7kd/9iC8=; b=v0eOr9KO6x0nZXl80dTY8Z2kcdbGqDrkrZffDnaVXQuio71UE6qa255VGYrAT097XW 2q9AkO/9H+c1qSKfEX52xmBSS4hQjyDS5pxhU/B+dbx4JT1BkOMKpjJr08OnMthnb9V+ nDDikMDzg5A/i3czncnYzSP96wfl44JHNJFsf5PTgQiOgCnDC8KMj0W1aT/cndvtVT37 Jcya+DQ4BZ0yarzVdyxJhRmoxEmH6uZnfFXB8QM1IbZpmuh0oq7oeiOfgQu65Y0n27RO iC7Zs1TA7IaAHLt4scNqgfPQU5lc1W8mmip4dgDeDQ1NEOtGpAMwookKwJyz1KNJ2oyL w7dA== X-Forwarded-Encrypted: i=1; AJvYcCWxRHmigwC7prX89QroRdNb4/il4y3lfZ++H6np74D7MUeHfoM6OY7kiDZqnsNksTWNMeKtCRQDHDz8Vfb75aUqFH/Q X-Gm-Message-State: AOJu0YwZGgkdxR4ihnRlWbiE0TB8kU+D/h40aM1lMqqe9enz2+XUJiBb yfXXGm5rfg6ljCWBCNncN0UXr7nPo7BThMliA5CiUkLr6sFaMHCBomr+JA== X-Google-Smtp-Source: AGHT+IH0YrNP3dCdx+/pLOreIxINLa4P+vNg1FHG388AdyIvX4/r7tnwoCfq3OrxgpjVr1Dyzz6cGA== X-Received: by 2002:a17:907:7f17:b0:a51:d70f:b5f2 with SMTP id qf23-20020a1709077f1700b00a51d70fb5f2mr3060171ejc.20.1713970992184; Wed, 24 Apr 2024 08:03:12 -0700 (PDT) Original-Received: from caladan ([89.107.106.118]) by smtp.gmail.com with ESMTPSA id f24-20020a170906c09800b00a522f867697sm8402913ejz.132.2024.04.24.08.03.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 08:03:11 -0700 (PDT) In-Reply-To: <86o79z2h7y.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Apr 2024 13:22:09 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=eller.helmut@gmail.com; helo=mail-ej1-x62b.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:318031 Archived-At: On Wed, Apr 24 2024, Eli Zaretskii wrote: >> And I was hoping you would say: "We don't need to collect markers. It's >> a nicety that was easy to do in the old GC. If it's not easy in the new >> GC, leave it out". > > Can we really do that? I don't think so, but maybe I'm missing > something. We don't need it for correctness. We would unlikely run out of memory. However, a buffer with an unreasonably long marker-chain will make some operations slower. How much slowness can we accept? I don't know; maybe I should measure this first. We could also provide functions to manually unlink markers from the buffer that programmers could use to keep the slowness in check. >> How would the main thread know that a marker is not referenced from >> anywhere else than from the undo-list? Are you saying the main thread >> should still do some marking as the old GC did, so that it can make the >> decisions on the same mark bits? > > Can't the new GC tell us which markers are unreferenced? The MPS supports finalization and weak references. Finalization could tell us which markers are unreferenced. The problem is that markers stay referenced as long as they are part of the buffer's marker-chain or the undo-list. That's why we could use weak references here. If a marker is referenced only through weak references then MPS can collect it. MPS will also set the weak reference to 0 when the marker has been collected. So that we know when we no longer can/need to update the marker. The old GC knows which references are weak; that's what the special code there is for. For MPS, we somehow need to tell it which references are weak. Helmut