GNU bug report logs - #37006
27.0.50; garbage collection not happening after 26de2d42

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jrm <at> ftfl.ca, mattiase <at> acm.org, 37006 <at> debbugs.gnu.org
Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42
Date: Wed, 14 Aug 2019 18:37:44 -0700

Eli Zaretskii wrote:

> However, I'd rather we don't invent new data types unless really
> necessary.

I did that yesterday, in commit 2019-08-13T19:20:40Z!eggert <at> cs.ucla.edu 
(b80559be212292d44ce14ca5e94505cab4d9a868).

> gc-cons-threshold is a Lisp integer, a
> fixnum, so it cannot exceed EMACS_INT_MAX, I think.

No, (setq gc-cons-threshold (1+ most-positive-fixnum)) works and does the right 
thing. 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.

> Can we use for this purpose the existing trapped_write
> field of Lisp_Symbol that is the base for implementing Lisp watcher
> functions?

Don't see why not.

> With the old code, whenever memory-full was non-nil, and
> consing_since_gc was more than the size of cons_block (about 1KB on my
> system), the very next maybe_gc call would actually trigger GC.  With
> the new code, no matter how much consing happened before memory-full
> became non-nil, we still need to cons 1KB worth of objects before GC
> happens.  This 1KB might be critical when we are out of memory.

I don't think the scenario is worth worrying about doing a GC now rather than 
later. But if we go the trapped_write route, this issue won't matter since the 
GC will be done quickly.

>> Immediate-GC might cause GC thrashing, no?
> 
> Not sure how, can you elaborate?

When EMacs is low on memory, if we're not careful Emacs could GC every time 
maybe_gc is called, which will be roughly equivalent to Emacs hanging and doing 
nothing.

Previous Next

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