From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 14:08:23 -0400 Message-ID: <20140625180823.GV179@brightrain.aerifal.cx> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403720485 16654 80.91.229.3 (25 Jun 2014 18:21:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 18:21:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 20:21:18 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wzroo-0001dQ-RV for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 20:21:14 +0200 Original-Received: from localhost ([::1]:40350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzroo-0003sL-CG for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 14:21:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzrcf-0005za-LR for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:08:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzrcY-00005R-WD for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:08:41 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:44418 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzrcY-000052-Rg for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:08:34 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1WzrcN-0002lC-00; Wed, 25 Jun 2014 18:08:23 +0000 Content-Disposition: inline In-Reply-To: <53AB0EF8.4090608@yandex.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-Mailman-Approved-At: Wed, 25 Jun 2014 14:21:12 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172713 Archived-At: 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