From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org
Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42
Date: Thu, 15 Aug 2019 22:34:27 +0300 [thread overview]
Message-ID: <83mugap6ik.fsf@gnu.org> (raw)
In-Reply-To: <58673b86-d27f-c839-2eb6-bd0cbe7a70a5@cs.ucla.edu> (message from Paul Eggert on Thu, 15 Aug 2019 11:51:06 -0700)
> Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 15 Aug 2019 11:51:06 -0700
>
> > most-positive-fixnum on 32-bit systems is large enough for
> > every practical purpose.
>
> It's not that hard for the number of consed bytes to exceed most-positive-fixnum
> on a 32-bit Emacs. Here's a simple test case to illustrate the phenomenon:
>
> (let* ((cons-size (car (cdr (car (garbage-collect)))))
> (long-length (1+ (/ most-positive-fixnum cons-size)))
> (l (make-list long-length nil)))
> (cons most-positive-fixnum (* cons-size (length l))))
>
> This yielded (536870911 . 536870912) on the 32-bit Emacs that I just built. Of
> course a practical application would likely have a bunch of smaller lists, but
> the same basic idea applies. On such a platform, a user who wants to disable GC
> while fiddling with a bunch of large lists will need to set gc-cons-threshold to
> a bignum.
I don't see why we must complicate our code to support such a use
case. Users who want to disable GC while consing so much object will
have to learn that they cannot, not on a 32-bit machine.
> > supporting the full 32 bits (and 64
> > bits in 64-bit builds) will also allow contradictory situation whereby
> > gc-cons-threshold is higher than what we say should be used to disable
> > GC.
>
> Sorry, I'm not following. If setting gc-cons-threshold to a large value
> effectively disables GC, then setting gc-cons-threshold to a larger value should
> do the same thing.
most-positive-fixnum is infinity for this purpose, and there should
not be numbers greater than infinity. It's confusing and hard to
explain.
> > Why do we need to talk about how many objects are there? GC threshold
> > is not about counting objects, it's about deciding when to GC.
>
> The GC threshold is part of a related set of integers that count objects and
> bytes, for use in the returned value of garbage-collect among other things.
No, they are just a means to decide when it's a good time to GC. Very
large values are used to effectively disable GC, very small values to
cause GC "soon". That's all, there are no requirements to count
objects or to have any accurate bookeeping of how many objects or
bytes were consed.
> > Are you working on that, or should someone else do it?
>
> I can add it to my list of things to do. To my mind, getting the timestamp API
> nailed down is more urgent, though, because fiddling with GC heuristics doesn't
> affect the API.
Well, meanwhile we've broken a very popular use case, so I think
fixing this is rather urgent.
> > Right, but that's not what I proposed. I proposed to trigger an
> > immediate GC only the first time we detect memory-full. Thereafter,
> > the threshold will be set to 1KB, which should prevent thrashing.
>
> Isn't it more complicated than that? Emacs can be low on memory, but can then
> get more and not be low on memory, and then be low on memory again later.
Maybe so, but we had such code in Emacs for decades. I just want to
avoid losing those features.
next prev parent reply other threads:[~2019-08-15 19:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org>
2019-08-11 16:23 ` bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Mattias Engdegård
2019-08-11 17:07 ` Eli Zaretskii
[not found] ` <83h86nu0pq.fsf@gnu.org>
[not found] ` <86pnlbphus.fsf@phe.ftfl.ca>
2019-08-12 2:31 ` Eli Zaretskii
2019-08-12 14:34 ` Joseph Mingrone
2019-08-12 16:49 ` Eli Zaretskii
2019-08-12 17:00 ` Mattias Engdegård
2019-08-13 15:37 ` Eli Zaretskii
2019-08-13 16:48 ` Mattias Engdegård
2019-08-13 17:04 ` Eli Zaretskii
2019-08-13 17:29 ` Mattias Engdegård
2019-08-13 17:21 ` Paul Eggert
2019-08-13 17:53 ` Eli Zaretskii
2019-08-13 19:32 ` Paul Eggert
2019-08-14 16:06 ` Eli Zaretskii
2019-08-15 1:37 ` Paul Eggert
2019-08-15 14:17 ` Eli Zaretskii
2019-08-15 18:51 ` Paul Eggert
2019-08-15 19:34 ` Eli Zaretskii [this message]
2019-09-14 7:51 ` Paul Eggert
2019-09-14 8:30 ` Eli Zaretskii
2019-08-11 12:39 Joseph Mingrone
2019-08-11 15:13 ` Eli Zaretskii
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=83mugap6ik.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=37006@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=jrm@ftfl.ca \
--cc=mattiase@acm.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.