[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17713: First portion of `bt full`

From: Geoff Shannon
Subject: bug#17713: First portion of `bt full`
Date: Fri, 6 Jun 2014 01:51:42 -0700

On Fri, Jun 6, 2014 at 1:21 AM, Eli Zaretskii <address@hidden> wrote:
> From: Geoff Shannon <address@hidden>
> Date: Fri, 6 Jun 2014 01:06:43 -0700
> Cc: address@hidden
> > 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'.


Nothing is ever easy.

reply via email to

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