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: Wed, 26 May 2021 15:30:17 +0300 Message-ID: <83zgwhad9i.fsf@gnu.org> References: <87v978u3nd.fsf@mbork.pl> <83im38e2qv.fsf@gnu.org> <875yz6drjd.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="39816"; 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 Wed May 26 14:32:56 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 1llsiV-000A71-VZ for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 26 May 2021 14:32:55 +0200 Original-Received: from localhost ([::1]:41418 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llsiV-0005kG-20 for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 26 May 2021 08:32:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39118) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llsg0-0004PT-FH for help-gnu-emacs@gnu.org; Wed, 26 May 2021 08:30:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60774) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llsg0-00011h-7p for help-gnu-emacs@gnu.org; Wed, 26 May 2021 08:30:20 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2135 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 1llsfy-0005jW-Ps for help-gnu-emacs@gnu.org; Wed, 26 May 2021 08:30:19 -0400 In-Reply-To: <875yz6drjd.fsf@mbork.pl> (message from Marcin Borkowski on Wed, 26 May 2021 06:53:42 +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:130239 Archived-At: > From: Marcin Borkowski > Cc: help-gnu-emacs@gnu.org > Date: Wed, 26 May 2021 06:53:42 +0200 > > But what would happen if I (delete-overlay my-overlay), then it gets > garbage collected, and then I (move-overlay my-overlay ...)? > > I just performed a simple experiment - I manually created an overlay in > a temporary buffer, bound a variable to it, deleted it, and called > (garbage-collect) - and C-h v'ing that variable still said: > > aqq’s value is # > > so I assume it was /not/ GCed. It wasn't GCed because it was referenced from a variable. > >> 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. > > I am not sure if I grasp that difference. Can you provide an example of > a situation when an object does not have an "actual reference" but still > "can be referenced"? Do you mean e.g. it being an element of a list > bound to some variable? No, that's not the essence of the difference. You said, above, "it can't be referenced from Lisp". My point is that "can't" doesn't cut it, because an object can be GCed even if it _can_ be referenced. What matters is that it _is_not_ referenced, even though it _can_be_. IOW, any object can potentially be referenced by some variable, but GC only avoids recycling an object if some other object actually (not potentially) references it. The GC's "mark" phase scans all the live Lisp objects and marks any other objects referenced by those live objects, recursively. Any marked object will not be recycled by the "sweep" phase. > Well, I meant something different - an overlay that is "live" in some > buffer, but no variable is bound to it. Such an overlay /can/ be > referenced with `overlays-in' / `overlays-at', so obviously cannot be > GCed, right? No live overlay in a live buffer will ever be GCed, because when GC marks live buffers, it also marks the overlays in that buffer by walking the linked list of the buffer's overlays.