From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: w32/w64 Emacs and gmalloc() Date: Fri, 28 Feb 2014 12:21:37 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393608108 14885 80.91.229.3 (28 Feb 2014 17:21:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Feb 2014 17:21:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 28 18:21:56 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 1WJR8G-0002hB-0u for ged-emacs-devel@m.gmane.org; Fri, 28 Feb 2014 18:21:56 +0100 Original-Received: from localhost ([::1]:52458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJR8F-0002xt-BK for ged-emacs-devel@m.gmane.org; Fri, 28 Feb 2014 12:21:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJR85-0002x3-TC for emacs-devel@gnu.org; Fri, 28 Feb 2014 12:21:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJR7y-0005K7-JO for emacs-devel@gnu.org; Fri, 28 Feb 2014 12:21:45 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJR7y-0005K0-FU for emacs-devel@gnu.org; Fri, 28 Feb 2014 12:21:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KLz/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFHO+KLz/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="48999827" Original-Received: from 206-248-162-243.dsl.teksavvy.com (HELO pastel.home) ([206.248.162.243]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Feb 2014 12:21:37 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 13E5760452; Fri, 28 Feb 2014 12:21:37 -0500 (EST) In-Reply-To: (Fabrice Popineau's message of "Fri, 28 Feb 2014 16:39:04 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169952 Archived-At: > 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? > 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? If so, there's still some room for improvement since Emacs could reuse a malloc'd area internally (without going through free+malloc). > Any comments welcome on the pros/cons of this gmalloc removal for w32. Can you show your current patch (I promise I won't make any comment about style etc...). Stefan