emacs-devel
[Top][All Lists]
Advanced

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

Re: Larger GC thresholds for non-interactive Emacs


From: Eli Zaretskii
Subject: Re: Larger GC thresholds for non-interactive Emacs
Date: Sat, 25 Jun 2022 09:08:11 +0300

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Mattias EngdegÄrd
>  <mattiase@acm.org>,  Eli Zaretskii <eliz@gnu.org>,  Tim Cross
>  <theophilusx@gmail.com>,  rms@gnu.org,  Alan Mackenzie <acm@muc.de>,
>   emacs-devel <emacs-devel@gnu.org>
> Date: Sat, 25 Jun 2022 13:13:22 +0800
> 
> > Not at all.  The general rule of thumb is: the sooner you recover free
> > space, the better you can avoid fragmentation.
> 
> Sure. But how does the probability to get fragmentation scale with the
> GC threshold? Is it linear scaling or is it nonlinear (I suspect that it
> is non-linear)? Can someone quantify it? If we do, it would help to
> adjust the thresholds more optimally to balance between GC time and
> fragmentation.

The answer depends on the C library being used.  If you are talking
about glibc, there's still the question of the statistics of
allocation size distribution, because AFAIK glibc's malloc
implementation uses several separate lists to manage the arena, each
list for allocations between X and Y bytes, where X and Y are
different for each list.  And for allocations larger than 64KB we
instruct glibc to use mmap, where there should be no fragmentation at
all.



reply via email to

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