Re: When should ralloc.c be used? (WAS: bug#24358)

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> Date: Sun, 23 Oct 2016 20:21:33 -0400
> 
>   > I don't like it either, but would rather work on redoing the build 
> process so 
>   > that we can use the native malloc on all hosts.
> 
> That may not be desirable, though.  We started using GNU malloc
> because it gave much better performance than some native mallocs.
> Whether that is true today, I have no idea; I am only saying
> that it is an issue to consider.

I think native malloc on GNU/Linux is much better these days; we were
using it all the recent years, until glibc developers removed the
hooks we needed for unexec support (which is why those GNU/Linux
systems where this change is already installed switched to gmalloc and
ralloc instead).

Emacs 25.1 switched to native malloc on MS-Windows as well, and I see
no problems with memory management due to that, perhaps even a small
improvement.

>   > But that doesn't explain why we'd need to use ralloc in the mean time.
> 
> Why would we not want to use ralloc?

It imposes hard-to-fulfill requirements on functions that get C
pointers to buffer text or to Lisp string data: those functions must
never call malloc, directly or indirectly.

This requirement was well known to the few Emacs developers in the
distant past, when all the platforms used ralloc.  But since the
modern platforms gradually migrated away from ralloc, this is almost
unknown to most current developers, and code crept in that violates
this requirement.  Fixing all that code is hard, because most of it is
not easily found; it manifests itself in corruption of buffer text,
random segfaults and aborts during GC, which happen long time after
the offending code did its job.

> It made a big improvement for memory management when I wrote it.

It is no longer a big improvement, as modern platforms manage memory
much better in their native malloc implementations.  So ralloc is
nowadays a significant disadvantage almost without advantages.