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:20:40 +0300 Message-ID: <831tucrguf.fsf@gnu.org> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403720477 16526 80.91.229.3 (25 Jun 2014 18:21:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 18:21:17 +0000 (UTC) Cc: dalias@libc.org, 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:09 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 1Wzrod-0001UR-Br for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 20:21:03 +0200 Original-Received: from localhost ([::1]:40345 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzroc-0003Uu-RA for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 14:21:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzroT-0003Ma-DF for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:20:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzroN-0005hX-0G for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:20:53 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:44911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzroM-0005hB-Kc for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:20:46 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N7Q00J00L5XV900@mtaout27.012.net.il> for emacs-devel@gnu.org; Wed, 25 Jun 2014 21:17:24 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7Q00IPVLH0YI20@mtaout27.012.net.il>; Wed, 25 Jun 2014 21:17:24 +0300 (IDT) In-reply-to: <53AB0EF8.4090608@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:172712 Archived-At: > Date: Wed, 25 Jun 2014 22:03:36 +0400 > From: Dmitry Antipov > 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. Is it possible to provide our own implementation of sbrk that allocates memory from some large static array? Or do modern malloc implementations avoid calling sbrk when they need more memory? If something like that is possible, we could do what the native and Cygwin Windows builds already do: record all the objects, Lisp and C, in that static array, which then gets dumped as part of the data section. > What about stuff allocated by some external library? A valid concern, but I don't think we have that problem now. If we did, the Windows port would not be able to be built, because such external libraries would call the malloc they were linked against, not the replacement we provide during "-l loadup dump" phase of the build.