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

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

bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacO


From: Przemysław Alexander Kamiński
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





reply via email to

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