bug#17713: First portion of `bt full`

[Geoff Shannon]

On Fri, Jun 6, 2014 at 1:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Geoff Shannon <geoffpshannon@gmail.com>
> Date: Fri, 6 Jun 2014 01:06:43 -0700
> Cc: 17713@debbugs.gnu.org

>
> > Did you customize any GC-related options, like gc-cons-threshold?
>
> I didn't personally, but I use emacs Prelude which does this:
>
> (setq gc-cons-threshold 50000000)

That's 50MB!  The default is 400000 (400K).

> I'm guessing that's likely the cause of this?

Could well be.  It means Emacs invokes GC after it has created at
least 50MB worth of Lisp objects.  Wading through all of them and
finding those which can be discarded will indeed take a while.

I suggest you remove that customization.  The default is well tuned,
and you will hardly ever notice GC going on.

I'm very on board with using the default, especially if this is a possible result.

Also, some more evidence which seems to my gc-cons-threshold as the problem:

It appears that the 'hung' emacs is still responsive, _occasionally_.  As in, during a

random test for responsive-ness (i.e. mashing on the keyboard) I got the cursor to

move one space forwards.  Then no more.

My theory is that the GC is running (which takes a while because it was allowed to get
so big).  Then because it's not getting much smaller (am I correct in thinking that emacs
does conservative GC?), it almost immediately goes back to trying to GC, which

again takes a while.

Basically, since the number of lisp objects is so large, the GC takes up way too much

time since it takes so long to run. So the trade-off for putting that limit so high is

no garbage collection for a LONG time, and then after that garbage collection takes
all the available time...  Not good.

So, if this theory is correct, then the reproduction of this bug should be to use emacs for

a while with the gc-cons-threshold turned up high.  And eventually this should happen again.

Seems like this can probably be closed as 'User error'.

--

Geoff

Nothing is ever easy.