[Top][All Lists]

[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: Tue, 13 Aug 2019 12:32:24 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Eli Zaretskii wrote:

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.

Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since gc-cons-threshold could exceed EMACS_INT_MAX. So I installed the second attached patch to do that.

I don't see why the threshold needs to be recomputed on each maybe_gc call. I
suppose we could add a new builtin variable type, so that the threshold could be
recomputed whenever GC-related builtin variables are changed; that should do the
trick without slowing down maybe_gc.

I don't think I understand what this proposal means in practice.  Can
you elaborate, or show an example?

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.

How else would you succeed in reacting to the change "soon enough"?

There are other possibilities. We could have a timer, for example.
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!address@hidden (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.

I think the code in memory_full which sets
consing_until_gc should be amended to (a) not raise consing_until_gc
if the current value is already below memory_full_cons_threshold, and
(b) probably even set it to the negative of sizeof (struct cons_block)
so as to cause an immediate GC.

Immediate-GC might cause GC thrashing, no? But (a) makes sense so I installed the third attached patch.

Attachment: 0001-Let-consing_until_gc-exceed-INTPTR_MAX.patch
Description: Text Data

Attachment: 0002-Let-consing_until_gc-exceed-EMACS_INT_MAX.patch
Description: Text Data

Attachment: 0003-Don-t-increase-consing_until_gc-when-out-of-memory.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]