unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Dumper problems and a possible solutions
Date: Wed, 25 Jun 2014 14:08:23 -0400	[thread overview]
Message-ID: <20140625180823.GV179@brightrain.aerifal.cx> (raw)
In-Reply-To: <53AB0EF8.4090608@yandex.ru>

On Wed, Jun 25, 2014 at 10:03:36PM +0400, Dmitry Antipov wrote:
> On 06/24/2014 09:19 PM, Rich Felker wrote:
> 
> >To solve ALL of the problems with the dumper (which seems to be a
> >recurring theme), I have a proposed design to make it fully portable
> >-- even moreso than xemacs "portable dumper" which is still an ugly
> >hack. The idea is simple: after loading all of the lisp objects that
> >need dumping, walk the lisp heap and output a representation for each
> >object as a giant static array in C source format, then compile and
> >link this new translation unit with the rest of the emacs .o files to
> >produce a final emacs binary.
> 
> 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?

Rich



  reply	other threads:[~2014-06-25 18:08 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 [this message]
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
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=20140625180823.GV179@brightrain.aerifal.cx \
    --to=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).