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: Enlarge MAX_ALLOCA? Date: Fri, 20 Jun 2014 10:43:10 -0400 Message-ID: References: <83sin0sx98.fsf@gnu.org> <83lhsssq1b.fsf@gnu.org> <83ionwrrc6.fsf@gnu.org> <83zjh7ra6a.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403275428 30831 80.91.229.3 (20 Jun 2014 14:43:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Jun 2014 14:43:48 +0000 (UTC) Cc: handa@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 20 16:43:41 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 1Wy02W-0000uw-Kd for ged-emacs-devel@m.gmane.org; Fri, 20 Jun 2014 16:43:40 +0200 Original-Received: from localhost ([::1]:41413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wy02V-0007jM-Vh for ged-emacs-devel@m.gmane.org; Fri, 20 Jun 2014 10:43:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wy02K-0007h8-Tj for emacs-devel@gnu.org; Fri, 20 Jun 2014 10:43:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wy02C-000207-Cr for emacs-devel@gnu.org; Fri, 20 Jun 2014 10:43:28 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:54524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wy023-0001yj-HT; Fri, 20 Jun 2014 10:43:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOI1cHhDgEoyqFb4Fqg0whgS0 X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOI1cHhDgEoyqFb4Fqg0whgS0 X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="68760652" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Jun 2014 10:43:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5BBB360D09; Fri, 20 Jun 2014 10:43:10 -0400 (EDT) In-Reply-To: <83zjh7ra6a.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 20 Jun 2014 16:18:53 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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:172572 Archived-At: >> > Alternatively, how about using a different limit just in the 2 users >> > of ALLOC_CONVERSION_WORK_AREA? >> Why not just use `alloca' directly for those cases, then? > With an assertion in case the size is enlarged some day? OK. >> >> Is this memory fragmentation problem hypothetical, or have we seen >> >> evidence of it? >> > Hypothetical. I just don't like seeing such frequent sequences of >> > malloc(64K)/free() one after the other several times a second in a >> > live session. >> I'd expect any non-toy implementation of malloc/free to handle this >> without any serious risk of fragmentation, to tell you the truth. > gmalloc doesn't, at least not with ralloc.c. One of my systems keeps > growing in memory, and the only reason I could find is these constant > allocations. I see, so it's not just hypothetical (tho the evidence is circumstantial, as is usually the case: proving fragmentation is difficult). So I think the way to go is the following: - see if we can allocate this area less frequently (e.g. if it's for handling compositions, it seems like it shouldn't be needed in your cases where you encode file names (or do your file names have parts that require compositions?)). I.e. delay the allocation to when we really need it. - try to reduce the size of this area. - if the above two is not sufficient, try and just use plain `alloca' (tho the "delay allocation" part above might make it difficult/impossible to use alloca). > Strange thing is, this only happens on 1 of 3 systems I use regularly, > which all have almost identical setup. Try to put him closer to the other 2 systems, so he'll feel ashamed. Stefan