GNU bug report logs - #79023
30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)

Previous Next

Full log

View this message in rfc822 format

From: Przemysław Alexander Kamiński
 <przemyslaw <at> kaminski.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79023 <at> debbugs.gnu.org
Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)
Date: Wed, 16 Jul 2025 14:35:51 +0200

> I also am not sure these are real leaks.  Emacs Lisp programs trigger
> memory allocation when they create Lisp objects, but they don't
> themselves free memory they allocated this way when the objects are no
> longer needed.  Instead, the process known as "garbage collection"
> (GC) is initiated by Emacs from time to time, and "collects garbage"
> by finding Lisp objects no longer referenced by any other object, and
> freeing their memory.  (Apologies for the lecture if you already know
> all that.)  Thus, programs that expect memory to be released
> immediately when the object goes out of scope will think Emacs is a
> very leaky application, because that's not how Emacs Lisp works.
>
> Are you sure the information you collected is not of this kind?

I'm quite confident it's not the case. Garbage collector doesn't clean it up.

Here's my line of thinking:
- 1Gb of Emacs after launch and list-packages is huge (even with hefty config)
- This wouldn't go unnoticed, so most likely isn't the problem of the core code...
- I searched before and found also other entries on web which point to Emacs performance on MacOS
- Also I have Emacs config synced to my gaming Windows machine and I didn't experience any slowness (it was blazingly fast actually)
- All profiling I've done so far look good
- Which means something must be happening on MacOS integration

The facts for me are:
- Emacs is bloating over time and freezes at some point for unknown reasons
- Over the time Emacs is more and more slugish, M-x taking 0.7s to think etc.
- After multiple scrupoulous review of config, timers background processess etc.

I've noticed that on built Emacs there's allocation for every single blink of cursor on screen. Isn't this weird even if that wouldn't leak.

I've done more testing today with different build flags and some guesses that I have:
- Some allocated strings aren't marked as autorelease, so they stay
- For some reason system doesn't know that this allocated space is no longer used and doesn't GC it
- Slowness is caused by immense fragmentation of memory caused by small allocations far away from each other
- During deallocation hashes aren't deallocated completely
- There's missing some MacOS specific call that should be made in order for it to optimize
- NSEvents are being stopped in flight without deallocation and they keep references to the memory

However, after working in recent months with Zig and C I've been able to get instrumentation running on MacOS and I'd like to fix it.

Best,
Przemysław Alexander Kamiński

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.