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:49:42 +0300 Message-ID: <83wqc4q0xl.fsf@gnu.org> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <831tucrguf.fsf@gnu.org> <20140625183241.GW179@brightrain.aerifal.cx> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403722216 6409 80.91.229.3 (25 Jun 2014 18:50:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 18:50:16 +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:50: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 1WzsGl-0000FK-9U for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 20:50:07 +0200 Original-Received: from localhost ([::1]:40446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzsGk-0005Pc-OI for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 14:50:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzsGa-0005OU-1U for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:50:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzsGT-0001Te-Sd for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:49:55 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:48358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzsGT-0001TD-KZ for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:49:49 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N7Q00600MKUKH00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Wed, 25 Jun 2014 21:49:48 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7Q006MXMYZF550@a-mtaout22.012.net.il>; Wed, 25 Jun 2014 21:49:48 +0300 (IDT) In-reply-to: <20140625183241.GW179@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.172 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:172720 Archived-At: > Date: Wed, 25 Jun 2014 14:32:41 -0400 > From: Rich Felker > Cc: Dmitry Antipov , emacs-devel@gnu.org > > > Is it possible to provide our own implementation of sbrk that > > allocates memory from some large static array? > > That's exactly the hack I described which I'm using right now. But > since I didn't implement a free-like operation and since > load_charset_map_from_file allocates >700k every time it's called, I > had to make the static array 400MB. That's not a problem, because those 700K are free'd before the next one is allocated. And in any case, they are all free'd before we call unexec. Just implement sbrk for negative increment. The Windows port already does that, see w32heap.c on the trunk. It works with only 11MB of static array for 32-bit builds and 18MB for 64-bit. > I think it would work with a "real" mini-malloc implementation using > the static array, and a much smaller static array (maybe 8-15 MB) > but my attempts to write a quick one have been sloppy and buggy so > far. If supporting deallocation in such an sbrk isn't feasible, how about using gmalloc, as an malloc replacement before dumping? > I would be reasonably happy with this solution (at least it would fix > the problems I'm experiencing), but I don't think it's as elegant as > fixing the portability problem completely by getting rid of the need > to dump executable binary files and instead dumping a C array. But it's conceptually much simpler and reliable. That's "elegant" in my book, when such hairy stuff is concerned. > And it doesn't fix the fact that you can't build a PIE emacs. Why is that important?