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: w32/w64 Emacs and gmalloc() Date: Sat, 01 Mar 2014 09:02:23 +0200 Message-ID: <831tymwge8.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1393657346 32646 80.91.229.3 (1 Mar 2014 07:02:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2014 07:02:26 +0000 (UTC) Cc: fabrice.popineau@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 08:02:34 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 1WJdwQ-000709-FM for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 08:02:34 +0100 Original-Received: from localhost ([::1]:54400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJdwQ-0000t3-3m for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 02:02:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJdwH-0000n2-Di for emacs-devel@gnu.org; Sat, 01 Mar 2014 02:02:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJdwC-000580-5B for emacs-devel@gnu.org; Sat, 01 Mar 2014 02:02:25 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:37745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJdwB-00057s-TI for emacs-devel@gnu.org; Sat, 01 Mar 2014 02:02:20 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N1Q00K00VQZI800@mtaout26.012.net.il> for emacs-devel@gnu.org; Sat, 01 Mar 2014 09:00:16 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1Q00HCYWSG9K60@mtaout26.012.net.il>; Sat, 01 Mar 2014 09:00:16 +0200 (IST) In-reply-to: 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.182 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:169970 Archived-At: > From: Stefan Monnier > Date: Fri, 28 Feb 2014 12:21:37 -0500 > Cc: emacs-devel@gnu.org > > > Once the preloaded data are dumped, they are not freed nor realloc'ed, or > > rather, the space they occupied is not collected. > > What changes did you make to get this result? Fabrice implemented mmap emulation for Windows, for use in allocating buffer text, and then uses system malloc for the rest of allocations. > > This is suboptimal, but there is no way around with the w32 api alone > > (no way that I know of without using your own allocator). > > IIUC the problem is with calling "malloc" before the dump and then > "free" that block after the dump, right? Yes, that's the problem. > If so, there's still some room for improvement since Emacs could > reuse a malloc'd area internally (without going through > free+malloc). If Emacs already does that, there's no problem. What Fabrice wrote just says that calls to 'free' that reference memory allocated before dumping will be a no-op, and calls to 'realloc' that enlarge the block will malloc new memory.