[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33275: 27.0.50; Image cache pruning
From: |
Eli Zaretskii |
Subject: |
bug#33275: 27.0.50; Image cache pruning |
Date: |
Mon, 05 Nov 2018 21:24:42 +0200 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 33275@debbugs.gnu.org
> Date: Mon, 05 Nov 2018 20:06:41 +0100
>
> In general, if you don't have a reference to an object, you can be
> pretty sure that Emacs is going to garbage-collect it.
Of course. But you cannot control when that GC will happen.
> > That it doesn't is just sheer luck: the way we manage buffer memory is
> > special. With any other Lisp object, it could well grow
> > uncontrollably.
>
> What other non-referenced Lisp object can realistically make Emacs grow
> in this way?
Theoretically, anything. In practice, I've seen such situations with
fonts.
- bug#33275: 27.0.50; Image cache pruning, (continued)
- bug#33275: 27.0.50; Image cache pruning, Eli Zaretskii, 2018/11/05
- bug#33275: 27.0.50; Image cache pruning, Eli Zaretskii, 2018/11/05
- bug#33275: 27.0.50; Image cache pruning, Lars Ingebrigtsen, 2018/11/05
- bug#33275: 27.0.50; Image cache pruning, Eli Zaretskii, 2018/11/05
- bug#33275: 27.0.50; Image cache pruning, Lars Ingebrigtsen, 2018/11/09
- bug#33275: 27.0.50; Image cache pruning, Eli Zaretskii, 2018/11/06
- bug#33275: 27.0.50; Image cache pruning, Lars Ingebrigtsen, 2018/11/09
- bug#33275: 27.0.50; Image cache pruning, Eli Zaretskii, 2018/11/10
- bug#33275: 27.0.50; Image cache pruning, Eli Zaretskii, 2018/11/05
- bug#33275: 27.0.50; Image cache pruning, Lars Ingebrigtsen, 2018/11/05
- bug#33275: 27.0.50; Image cache pruning,
Eli Zaretskii <=