all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: When are unused overlays garbage collected?
Date: Mon, 24 May 2021 15:27:04 +0300	[thread overview]
Message-ID: <83im38e2qv.fsf@gnu.org> (raw)
In-Reply-To: <87v978u3nd.fsf@mbork.pl> (message from Marcin Borkowski on Mon,  24 May 2021 07:00:54 +0200)

> From: Marcin Borkowski <mbork@mbork.pl>
> 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.)



  parent reply	other threads:[~2021-05-24 12:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24  5:00 When are unused overlays garbage collected? Marcin Borkowski
2021-05-24  5:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-05-24  6:33   ` Marcin Borkowski
2021-05-24 12:27 ` Eli Zaretskii [this message]
2021-05-26  4:53   ` Marcin Borkowski
2021-05-26  7:23     ` tomas
2021-05-26 15:36       ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-05-26 16:52         ` tomas
2021-05-26 12:30     ` Eli Zaretskii
2021-05-27 16:20       ` Marcin Borkowski
2021-05-27 16:41         ` Eli Zaretskii
2021-05-28 19:38           ` Marcin Borkowski
2021-05-24 17:07 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-05-26  5:01   ` Marcin Borkowski
2021-05-26 12:34     ` Eli Zaretskii
2021-05-27 16:23       ` Marcin Borkowski
2021-05-26 14:48     ` Stefan Monnier
2021-05-27 16:26       ` Marcin Borkowski
2021-05-27 21:42         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83im38e2qv.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.