From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 21:41:25 +0300 Message-ID: <83y4wkq1be.fsf@gnu.org> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <20140625180823.GV179@brightrain.aerifal.cx> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403721715 32430 80.91.229.3 (25 Jun 2014 18:41:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 18:41:55 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Rich Felker Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 20:41:48 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 1Wzs8e-0001Y1-Ng for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 20:41:44 +0200 Original-Received: from localhost ([::1]:40418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzs8e-0002jR-BK for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 14:41:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzs8X-0002jB-Jw for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:41:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wzs8S-0006Mh-Jx for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:41:37 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:38084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzs8S-0006ME-Bz for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:41:32 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N7Q00200MJ86I00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 25 Jun 2014 21:41:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7Q001ZWML6Y960@a-mtaout20.012.net.il>; Wed, 25 Jun 2014 21:41:31 +0300 (IDT) In-reply-to: <20140625180823.GV179@brightrain.aerifal.cx> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:172719 Archived-At: > Date: Wed, 25 Jun 2014 14:08:23 -0400 > From: Rich Felker > 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.