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.help Subject: Re: When are unused overlays garbage collected? Date: Mon, 24 May 2021 15:27:04 +0300 Message-ID: <83im38e2qv.fsf@gnu.org> References: <87v978u3nd.fsf@mbork.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26953"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 24 14:28:22 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1ll9h0-0006m1-OZ for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 24 May 2021 14:28:22 +0200 Original-Received: from localhost ([::1]:54188 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll9gz-0002kO-P5 for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 24 May 2021 08:28:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ll9ft-0002il-60 for help-gnu-emacs@gnu.org; Mon, 24 May 2021 08:27:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35832) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll9fs-0002lq-9S for help-gnu-emacs@gnu.org; Mon, 24 May 2021 08:27:12 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2670 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ll9fq-0006Nc-Jb for help-gnu-emacs@gnu.org; Mon, 24 May 2021 08:27:12 -0400 In-Reply-To: <87v978u3nd.fsf@mbork.pl> (message from Marcin Borkowski on Mon, 24 May 2021 07:00:54 +0200) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:130177 Archived-At: > From: Marcin Borkowski > Date: Mon, 24 May 2021 07:00:54 +0200 > > --8<---------------cut here---------------start------------->8--- > The overlay continues to exist as a Lisp object, and its property list > is unchanged, but it ceases to be attached to the buffer it belonged to, > and ceases to have any effect on display. > > A deleted overlay is not permanently disconnected. You can give it > a position in a buffer again by calling ‘move-overlay’. > --8<---------------cut here---------------end--------------->8--- > > So I assume that if I `delete-overlay', it means it cannot be > necessarily garbage-collected yet. Yes, it _can_ be GCed right away, at least in principle. But Emacs will not necessarily trigger GC right away, so the overlay will not necessarily be collected immediately, even if it isn't references from any other variable or structure anymore. > My guess would be that if the overlay is "deleted" (so it is not > attached to any buffer, either by means of `delete-overlay' or when its > buffer is killed) /and/ it can't be referenced from Elisp (e.g., there > is no variable bound to it). That's not entirely true. An overlay (like any other Lisp object) that was deleted will not be collected as long as some variable _actually_references_ it. That could be a Lisp variable or a C variable not exposed to Lisp. The difference between what I wrote and what you wrote is that the reference must actually exist, not only be possible. > This would make sense, because even if there is no variable bound to > an overlay which is not deleted, you can still get a reference to it > using any of the overlay-finding functions (`overlays-at' or > `overlays-in'). No, overlays-in and overlays-at will not find a deleted overlay. These functions walk the buffer's overlay list, and a deleted overlay is unlinked from that list. Does that answer your questions? (I'm not sure what is exactly your question, because you didn't describe the context in which this issue bothered you.)