bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#39413: 26.2; Emacs gets hung


From: chiaki-ishikawa-thunderbird-account
Subject: bug#39413: 26.2; Emacs gets hung
Date: Tue, 26 May 2020 00:50:15 +0900
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 2020/05/25 21:15, Noam Postavsky wrote:
chiaki-ishikawa-thunderbird-account <chiaki.ishikawa@ubin.jp> writes:

Short of lisp function, maybe I can add message print out in alloc.c
to print out such information so that it gets recorded in *Message*
buffer.
It is done only when gabage-collection-message is t and there should
be some throttling mechanism to avoid spamming the user.
Any pointer re the hook(s) short of rewriting alloc.c is
appreciated. Well, if worst comes to worst, I don't mind rewriting
alloc.c to create an array of fixed size to store the last dozen or so
GC-related information that is updated before and after invocation of
a certain GC entry point.
I can print that out after a long GC to learn the memory situation.
But that sounds a bit drastic. OTOH, it may be the only way to go.
That should probably work.  I see the current
garbage_collection_messages code uses message_nolog, I guess because
growing the *Messages* buffer could also trigger GC.

Thank you, I will probably do that.

Back in 18.x days, printing the message from within GC caused another GC invocation, thus emacs blew up due to stack flow after so many recursive calls.

I think having a static array of 10-20 cells to store previous GC info should work.

Stay tuned. I am really interested in WHERE/WHY this long pause occurs.: maybe Windows 10 memory allocation/ Virtual Box emulation/Linux kernel memory allocation, and AMD Ryzen CPU's cache replacement policy all add up.

Chiaki







reply via email to

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