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: Wed, 14 Aug 2019 19:06:49 +0300 [thread overview]
Message-ID: <83v9uzrasm.fsf@gnu.org> (raw)
In-Reply-To: <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Aug 2019 12:32:24 -0700)
> Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 13 Aug 2019 12:32:24 -0700
>
> > OBJECT_CT_MAX should have the value EMACS_INT_MAX.
>
> Not if EMACS_INT_MAX < INTPTR_MAX, since object counts might overflow in that
> case. However, I take your point that consing_until_gc can easily be made to
> hold any fixnum value, so I installed the first attached patch. This is to some
> extent overkill, since these variables should not be assumed to have this sort
> of fine-grained control, but the change is tiny so should be fine.
Thanks.
However, I'd rather we don't invent new data types unless really
necessary. I think we should simply use EMACS_INT (see below), but
even if we end up using intptr_max, let's just use that directly, not
introduce yet another type which we will have to look up every time we
read this code. And likewise with the corresponding _MAX value.
Using a non-standard data type makes the code harder to read.
> Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since
> gc-cons-threshold could exceed EMACS_INT_MAX.
Sorry, I don't think I follow. gc-cons-threshold is a Lisp integer, a
fixnum, so it cannot exceed EMACS_INT_MAX, I think.
> The idea would be to have a type that is like struct Lisp_Objfwd but with an
> extra member, a function to be called whenever the variable is accessed. (Or
> perhaps two extra members, a getter and a setter.) This could be useful for
> other builtin vars, I suspect.
Ah, okay. Can we use for this purpose the existing trapped_write
field of Lisp_Symbol that is the base for implementing Lisp watcher
functions?
> > How else would you succeed in reacting to the change "soon enough"?
>
> There are other possibilities. We could have a timer, for example.
I don't think timers are reliable enough, as they can be deferred for
arbitrarily long time interval by some Lisp that takes a long time to
finish.
> >>> We must also notice the memory-full condition there.
> >>
> >> memory_full already does that, no? It sets consing_until_gc.
> >
> > It sets it to a positive value, so no immediate GC will follow. The
> > original code was setting the threshold to a very small value, so GC
> > would happen immediately.
>
> Are you talking about the change in commit
> 2019-07-20T02:40:03Z!eggert@cs.ucla.edu
> (26de2d42d0460c5b193456950a568cb04a29dc00)? If so, I'm not quite following, as
> the old code did not GC until consing_since_gc > memory_full_cons_threshold. I
> expect that the idea was to not thrash doing GCs when memory is full.
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.
> Immediate-GC might cause GC thrashing, no?
Not sure how, can you elaborate?
next prev parent reply other threads:[~2019-08-14 16:06 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 [this message]
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
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=83v9uzrasm.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.