Re: Indentation and gc

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org
> Date: Tue, 14 Mar 2023 12:47:29 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Noted. Can we measure fragmentation from Elisp?
> >
> > I think only on glibc platforms, where we have malloc-info.  The
> > output will need to be post-processed by some code, based on expert
> > knowledge of what the numbers mean.
> 
> But can we get the output from Elisp? `malloc-info' docstring says that
> the output is done directly to srderr, which we cannot (?) access from
> Elisp.

Yes.  But as I said, I'm not sure this information is useful, unless
you are a glibc memory-allocation expert.  When we needed to
understand these reports, we asked glibc developers for help.

> >> Does memory-limit include the fragmented memory segments?
> >
> > I think it does, although it's system-dependent.  It's basically what
> > 'top' shows as VSIZE.
> 
> At least, it can indirectly demonstrate the impact of GC threshold onto
> Emacs memory footprint. I guess it is what we worry about at the end.
> Or does the fragmentation cause other severe effects in addition to
> higher memory usage?

_Real_ memory fragmentation, if it happens in Emacs, should cause the
memory footprint grow all the time without leveling out, and
malloc-info should then show that most of the memory is in small
chunks that cannot be spliced together.

However, I have yet to see a platform where Emacs causes memory
fragmentation.  Where the system malloc cannot be trusted, we use
gmalloc (and in the past used ralloc).  Most modern platforms have
reliable malloc these days (the single known exception is MSDOS), so
this problem largely doesn't exist.