From: Eli Zaretskii <eliz@gnu.org>
To: Rich Felker <dalias@libc.org>
Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
Subject: Re: Dumper problems and a possible solutions
Date: Wed, 25 Jun 2014 21:41:25 +0300 [thread overview]
Message-ID: <83y4wkq1be.fsf@gnu.org> (raw)
In-Reply-To: <20140625180823.GV179@brightrain.aerifal.cx>
> Date: Wed, 25 Jun 2014 14:08:23 -0400
> From: Rich Felker <dalias@libc.org>
> 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. 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.
next prev parent reply other threads:[~2014-06-25 18:41 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 17:19 Dumper problems and a possible solutions Rich Felker
2014-06-24 19:27 ` Stefan Monnier
2014-06-24 19:40 ` Rich Felker
2014-06-24 20:24 ` Stefan Monnier
2014-06-24 21:15 ` Rich Felker
2014-06-24 21:37 ` Stefan Monnier
2014-06-25 18:03 ` Dmitry Antipov
2014-06-25 18:08 ` Rich Felker
2014-06-25 18:30 ` Dmitry Antipov
2014-06-25 18:36 ` Rich Felker
2014-06-25 18:36 ` Eli Zaretskii
2014-06-25 18:41 ` Eli Zaretskii [this message]
2014-06-26 0:16 ` Stephen J. Turnbull
2014-06-25 18:20 ` Eli Zaretskii
2014-06-25 18:32 ` Rich Felker
2014-06-25 18:49 ` Eli Zaretskii
2014-06-25 19:03 ` Rich Felker
2014-06-25 19:18 ` Eli Zaretskii
2014-06-25 19:57 ` Rich Felker
2014-06-25 20:15 ` Eli Zaretskii
2014-06-25 20:34 ` Rich Felker
2014-06-26 2:44 ` Eli Zaretskii
2014-06-26 4:28 ` Rich Felker
2014-06-26 15:02 ` Eli Zaretskii
2014-06-25 20:11 ` Stefan Monnier
2014-06-25 20:06 ` Stefan Monnier
2014-06-25 20:24 ` Rich Felker
2014-06-25 21:43 ` Stefan Monnier
2014-06-25 22:07 ` Rich Felker
2014-06-25 23:04 ` Paul Eggert
2014-06-25 23:21 ` Rich Felker
2014-06-25 23:05 ` Stefan Monnier
2014-06-25 23:19 ` Rich Felker
2014-06-26 3:02 ` Dmitry Antipov
2014-06-26 4:14 ` Rich Felker
2014-06-26 4:32 ` Dmitry Antipov
2014-06-26 11:49 ` Rich Felker
2014-06-26 15:03 ` Eli Zaretskii
2014-06-26 15:10 ` Rich Felker
2014-06-25 22:33 ` Andreas Schwab
2014-06-25 20:53 ` Samuel Bronson
2014-06-25 21:24 ` Rich Felker
2014-06-25 18:38 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y4wkq1be.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dalias@libc.org \
--cc=dmantipov@yandex.ru \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).