From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Collecting markers with MPS Date: Wed, 24 Apr 2024 18:54:07 +0300 Message-ID: <86bk5y3gf4.fsf@gnu.org> References: <87cyqfjk6n.fsf@gmail.com> <86sezb2oj2.fsf@gnu.org> <874jbrjg04.fsf@gmail.com> <86o79z2h7y.fsf@gnu.org> <87wmomiz0x.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="418"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 24 17:55:23 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 1rzext-000AKT-9S for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Apr 2024 17:55:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzewm-0003qJ-53; Wed, 24 Apr 2024 11:54:12 -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 1rzewk-0003py-Tt for emacs-devel@gnu.org; Wed, 24 Apr 2024 11:54:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzewk-0008FE-KT; Wed, 24 Apr 2024 11:54:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=A8NV1bVZ0na6KZTQk9g/Hzg2yudWOFkLEeDje6l4xdo=; b=MrwMfTiykWjv kpbhWgqHjqikWlL32gHeOhJ4ZALto0Fj6eXeMvMdP2Ax1E2FoDMnAN1eOvmlb4ZpOQNRTsTGf4FqA YdS7sktUOSvv83VGKOkuI2bENnWV3ZO41YHmD1t6e6ALIer1flJf/FcQAr2eLnqaZEZPH16Y/rKit AeTuZfvNvOl0vVloxtNYUxIjwkeCl3ikA8inWHSrQcxV1ExBk6PVIJ7DF2lBfoHXtp3wRI1cSi2Jm tdG5YCM0ly4ub5Xddt9nXs3tPnlCpl0JDnhqJhNSmt+xR0I7f4EBd/uYsBBeztBvaww0iAzzPhYxg N8iyD91ZdpAJ25WmdiaSHA==; In-Reply-To: <87wmomiz0x.fsf@gmail.com> (message from Helmut Eller on Wed, 24 Apr 2024 17:03:10 +0200) 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:318034 Archived-At: > From: Helmut Eller > Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org > Date: Wed, 24 Apr 2024 17:03:10 +0200 > > 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. Are you sure? Emacs could easily create gobs of markers. For example, if there are buffers with lost of non-ASCII characters, each time we need to compute character position from byte position or vice versa, we create more markers in the buffer. In a session that runs for weeks, there could be a lot of them, I think. > 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. I think we had in the past complaints from Ihor that some buffers with a lot of markers slowed down things. > We could also provide functions to manually unlink markers from the > buffer that programmers could use to keep the slowness in check. If we can do this manually, we should be able to do it from a timer, no? > 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. So why did you say this will take much more code than in the old GC?