bug#39413: 26.2; Emacs gets hung

[Eli Zaretskii]

> From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
> Date: Wed, 29 Apr 2020 06:36:46 +0900
> Cc: chiaki-ishikawa-thunderbird-account <chiaki.ishikawa@ubin.jp>,
>  Noam Postavsky <npostavs@gmail.com>
> 
> I am back to this strange guru meditation of emacs.
> Emacs would eventually begin working, but the silent period where no key
> or mouse event is acknowledged is rather longish.
> 
> Several weeks after I installed GNU Emacs 28.0.50 (that is what
> |emacs-version| variable says. I installed from git repo.) , I began
> noticing the occasional long pause (no response) again.

I suggest to begin by establishing whether these pauses are caused by
GC.  To that end, set garbage-collection-messages to a non-nil value,
and see if Emacs displays a message about GC in progress when these
pauses occur.  Also, try to tell how frequent are these pauses and
much time each pause takes.

If you see that every time you experience a pause there's GC running,
we can then proceed to investigating whether the frequency of GC and
the time it takes on your system is something abnormal, and why.

> So my take on this is sweep_conses() takes a rather long time and not
> letting emacs to take any input. (And there could be other functions
> before it.)

The question is how long is "long time".  We need some quantitative
measure of this before we can tell whether it's normal or not.

> Question.: Has there been any change in emacs's alloc.c code in the
> last year or two?

Yes, a lot.  But I don't see any significant change in frequency or
time duration of GC on my system due to those changes, FWIW.

> I am running emacs under Debian GNU/linux inside VirtualBox which is
> assigned 16GB memory.

It is possible that the virtual machine's memory management is
misconfigured, so it slows down Emacs when it needs to access a large
portion of its address space (which happens during GC).

> gc-elapsed is a variable defined in ‘C source code’.
> Its value is 68.3795433

The question is how many GC cycles took 68 seconds.  What is the value
of gcs-done?  Also, is this in a session to which you attached GDB? if
so, then some of the elapsed time was due to Emacs being stopped under
the debugger.  We need these values in a session that is never stopped
by a debugger.

> PS: Given that this may have something to do with the paging activity
> of the emacs process, the linux version change (from 4 to 5) may have
> affected the paging behavior of the program, but it is hard to say.  I
> now see this linux instance is using 293M SWAP.  Compiling mozilla
> thunderbird source runs |make -j6| and g++-9 compiles CPP source files
> which are very large and so they exert heavy memory pressure. A bad
> memory access pattern of emacs, not friendly to locality of access,
> would add to page faults. Except, |xosview| program does not show any
> paging activity. I am not sure if |xosview| is correct or not.

Building a large program with -j6 also uses CPU, and that could make
CPU-intensive operations, such as GC, slow.  Was that build running in
the same VirtualBox as Emacs?  If so, how many physical CPU execution
units do you have allocated to VirtualBox?