Re: Dumper problems and a possible solutions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 25 Jun 2014 14:32:41 -0400
> From: Rich Felker <dalias@libc.org>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>, emacs-devel@gnu.org
> 
> > Is it possible to provide our own implementation of sbrk that
> > allocates memory from some large static array?
> 
> That's exactly the hack I described which I'm using right now. But
> since I didn't implement a free-like operation and since
> load_charset_map_from_file allocates >700k every time it's called, I
> had to make the static array 400MB.

That's not a problem, because those 700K are free'd before the next
one is allocated.  And in any case, they are all free'd before we call
unexec.  Just implement sbrk for negative increment.  The Windows port
already does that, see w32heap.c on the trunk.  It works with only
11MB of static array for 32-bit builds and 18MB for 64-bit.

> I think it would work with a "real" mini-malloc implementation using
> the static array, and a much smaller static array (maybe 8-15 MB)
> but my attempts to write a quick one have been sloppy and buggy so
> far.

If supporting deallocation in such an sbrk isn't feasible, how about
using gmalloc, as an malloc replacement before dumping?

> I would be reasonably happy with this solution (at least it would fix
> the problems I'm experiencing), but I don't think it's as elegant as
> fixing the portability problem completely by getting rid of the need
> to dump executable binary files and instead dumping a C array.

But it's conceptually much simpler and reliable.  That's "elegant" in
my book, when such hairy stuff is concerned.

> And it doesn't fix the fact that you can't build a PIE emacs.

Why is that important?