[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37006: 27.0.50; garbage collection not happening after 26de2d42
From: |
Paul Eggert |
Subject: |
bug#37006: 27.0.50; garbage collection not happening after 26de2d42 |
Date: |
Thu, 15 Aug 2019 11:51:06 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
Eli Zaretskii wrote:
That makes gc-cons-threshold a bignum, right?
If the user sets it to a bignum, yes. Ordinarily it's not.
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.
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. This is independent of any particular large value that we
suggest in the manual.
The variable's value can be any intmax_t value. This is useful for
quantities like GC object byte counts that might not fit into fixnums.
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. It's
convenient for it to be as least as wide as those other integers, so that
calculations involving it do not overflow.
Don't see why not.
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.
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.
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, (continued)
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Paul Eggert, 2019/08/13
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Eli Zaretskii, 2019/08/13
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Paul Eggert, 2019/08/13
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Eli Zaretskii, 2019/08/14
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Paul Eggert, 2019/08/14
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Eli Zaretskii, 2019/08/15
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42,
Paul Eggert <=
- bug#37006: 27.0.50; garbage collection not happening after 26de2d42, Eli Zaretskii, 2019/08/15