Re: Dumper problems and a possible solutions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 25 Jun 2014 22:03:36 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: emacs-devel@gnu.org
> 
> What about non-Lisp objects?
> 
> It's not too hard to walk through live (reachable) Lisp objects - this
> is exactly what GC mark phase does. It's not too hard to walk through
> all allocated Lisp objects - this is exactly what GC sweep phase does.
> But what about lower-level stuff allocated with malloc at invisible
> from Lisp? Of course, you can do your own serialization for these objects
> as well - but only if you know about their internal structure.

Is it possible to provide our own implementation of sbrk that
allocates memory from some large static array?  Or do modern malloc
implementations avoid calling sbrk when they need more memory?

If something like that is possible, we could do what the native and
Cygwin Windows builds already do: record all the objects, Lisp and C,
in that static array, which then gets dumped as part of the data
section.

> What about stuff allocated by some external library?

A valid concern, but I don't think we have that problem now.  If we
did, the Windows port would not be able to be built, because such
external libraries would call the malloc they were linked against, not
the replacement we provide during "-l loadup dump" phase of the build.