GNU bug report logs - #33275
27.0.50; Image cache pruning

Previous Next

Package: emacs;

Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>

Date: Mon, 5 Nov 2018 14:09:02 UTC

Severity: normal

Tags: fixed

Found in version 27.0.50

Fixed in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33275 <at> debbugs.gnu.org
Subject: bug#33275: 27.0.50; Image cache pruning
Date: Mon, 05 Nov 2018 20:06:41 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> It would be reasonable if the code had asked for those images to be kept
>> in memory, but it hasn't.  Emacs decides that on its own without saying
>> that it's doing that.
>
> You cannot assume anything about memory management while a Lisp
> program runs.

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.  If you can't
assume that, then programming in Emacs Lisp becomes impossible.

Fortunately that's not the case, and programming in Emacs Lisp is nice
and easy.

>> It'd be similarly surprising if
>> 
>> (dolist (file (directory-files "/directory/with/many/images" t "png$"))
>>   (with-temp-buffer
>>     (insert-file-contents-literally file)))
>> 
>> were to lead to Emacs growing uncontrollably.
>
> 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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




This bug report was last modified 5 years and 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.