[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dumper problems and a possible solutions

From: Eli Zaretskii
Subject: Re: Dumper problems and a possible solutions
Date: Wed, 25 Jun 2014 21:41:25 +0300

> Date: Wed, 25 Jun 2014 14:08:23 -0400
> From: Rich Felker <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. What about
> > stuff allocated by some external library? In general, you can't parse heap
> > (i.e. looking at object, you can't say where the next object is, what is the
> > type of next object, etc.). IIUC, "totally portable" heap dumper is 
> > impossible
> > without having a description of each possible heap object and ability to
> > distinguish between different types of objects.
> Are there such objects that need to be preserved across dumping? This
> is a real question. I'm not familiar enough with emacs' internals to
> know whether there are or not, but my impression is that emacs does
> not need a fully general process-freeze-and-thaw dumper (in fact it
> doesn't even try to be one), and my hope is that only the lisp state,
> and perhaps some reasonably-trivial amount of non-lisp data with known
> structure, actually needs to be preserved.
> Can you or anyone else provide some answers to this question?

I don't think anyone knows the answer.  We've always dumped the entire
data segment, which includes everything, and never looked behind on
what exactly was dumped.

That said, I don't imagine we dump any non-Lisp data that is not
re-initialized after dumping anyway.  But the only way to know for
sure is to try.  E.g., run "temacs -l loadup dump" under a debugger or
some memory tracing tool, and see if there are any malloc calls that
allocate non-Lisp objects that are never freed before unexec runs.

Btw, would you like to subscribe to the list for the time being?  It
would definitely improve my life quality, as I would be spared the
need to release every of your messages for the list.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]