bug#17713: First portion of `bt full`

[Geoff Shannon <geoffpshannon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3233 bytes --]