GNU bug report logs -
#39413
26.2; Emacs gets hung
Previous Next
Full log
Message #81 received at 39413 <at> debbugs.gnu.org (full text, mbox):
On 2021/08/16 20:35, Eli Zaretskii wrote:
>> Cc: larsi <at> gnus.org, npostavs <at> gmail.com, 39413 <at> debbugs.gnu.org,
>> chiaki.ishikawa <at> ubin.jp
>> From: "ISHIKAWA,chiaki" <ishikawa <at> yk.rim.or.jp>
>> Date: Mon, 16 Aug 2021 08:27:01 +0900
>>
>> But if you look slightly above, you will notice CPU core #4 is used 100%
>> (!).
>> That is emacs process. No other process is running that earnestly at
>> that moment.
> If we believe everything these tools show us, maybe. But those tools
> suffer from the same problem Emacs does on a busy system: the tool
> itself might not get CPU to update its data, so you actually see a
> snapshot of what it saw last time it did get CPU.
>
>> PS: I found profiler-cpu-* functions, but I don't think it is wise to
>> run them during GC since they seem to allocate vector tables. However,
>> taking a snapshot of strack trace every now and then during GC seems
>> attractive for my investigation to figure out WHERE in GC, the excessive
>> time is spent.
> Emacs built-in profiling will not help us here, because it cannot
> profile below Lisp primitives.
>
Very tough.
I will see what I can do and report back if anything interesting shows up.
(The last time I tried to see where the time was spent, GC was busy
reclaiming |cons| cells.
May not mean much.
I can only recall the old paper and in an 16 GB environment (including
OS), we may see some bad behavior.
"
Address/memory management for a gigantic LISP environment or, GC
considered harmful
"
by Jon L. White
https://dl.acm.org/doi/abs/10.1145/800087.802797
This bug report was last modified 3 years and 211 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.