Re: Dumper problems and a possible solutions

[Rich Felker]

On Wed, Jun 25, 2014 at 09:20:40PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 25 Jun 2014 22:03:36 +0400
> > From: Dmitry Antipov <address@hidden>
> > Cc: address@hidden
> > 
> > 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?

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. This obviously isn't acceptable. 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.

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. And it
doesn't fix the fact that you can't build a PIE emacs.

> Or do modern malloc
> implementations avoid calling sbrk when they need more memory?

In general avoiding using brk to expand the heap is a bad idea on
Linux since alternate methods are considerably slower and can't
automatically obtain contiguous virtual space when it's available.
However, behaviors may vary.

In musl's malloc, we use brk if it's available (note: with PIE, most
kernels give you almost no available brk space due to the way the
mappings are laid out) for extending the heap that's usef for small
allocations, and fallback to constructing a discontiguous heap with
mmap if brk fails. However musl always uses mmap for huge allocations
(greater than ~100-200k) since it has no freelists for sizes that
large and since we want to always return freed memory that large to
the system.

Also, musl does not provide a working sbrk at all, since synchronizing
with an application's use of sbrk would introduce performance costs
into all correct applications that don't poke at the brk.

> 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.

Indeed.

Rich