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: Enlarge MAX_ALLOCA? Date: Fri, 20 Jun 2014 10:08:09 +0300 Message-ID: <83ionwrrc6.fsf@gnu.org> References: <83sin0sx98.fsf@gnu.org> <83lhsssq1b.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403248127 27627 80.91.229.3 (20 Jun 2014 07:08:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Jun 2014 07:08:47 +0000 (UTC) Cc: handa@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 20 09:08:40 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 1WxswB-000142-30 for ged-emacs-devel@m.gmane.org; Fri, 20 Jun 2014 09:08:39 +0200 Original-Received: from localhost ([::1]:39309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxswA-0000ty-Jr for ged-emacs-devel@m.gmane.org; Fri, 20 Jun 2014 03:08:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxsw2-0000mQ-EE for emacs-devel@gnu.org; Fri, 20 Jun 2014 03:08:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wxsvw-0003yS-6Y for emacs-devel@gnu.org; Fri, 20 Jun 2014 03:08:30 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:50747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxsvv-0003y6-V9; Fri, 20 Jun 2014 03:08:24 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N7G00800GKTUD00@mtaout27.012.net.il>; Fri, 20 Jun 2014 10:05:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7G00AIWH0QDE00@mtaout27.012.net.il>; Fri, 20 Jun 2014 10:05:14 +0300 (IDT) 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.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:172551 Archived-At: > From: Stefan Monnier > Cc: Kenichi Handa , emacs-devel@gnu.org > Date: Thu, 19 Jun 2014 16:37:07 -0400 > > >> It makes the potential max increment of stack space "per > >> lisp-eval-depth" larger, and hence increases the risk that we'll eat up > >> our stack before we bump into max-lisp-eval-depth. > > Which functions relevant to max-lisp-eval-depth use SAFE_ALLOCA? > > I don't know. Maybe none, but that would surprise me. I will take a look. Alternatively, how about using a different limit just in the 2 users of ALLOC_CONVERSION_WORK_AREA? > >> I think it makes a lot of sense to try and allocate this space on the > >> stack when decoding file names, but why does it allocate such a huge > >> buffer just to en/decode a puny file name? > > That buffer is fixed in size, I don't know why. Perhaps it's hard to > > know in advance how much we will need. > > Supposedly, every coding system comes with a "blow up factor" (can't > remember the name we use) which should be usable to compute a safe > upper-bound. I don't think the work area is what you think it is. It is not for the result of the encoding/decoding; that is allocated elsewhere, and indeed uses a dynamic size computed from the source size. This work area is for something else: for handling composition annotations (whatever that is). See handle_composition_annotation and produce_annotation in coding.c. > > Again, the problem is memory fragmentation and the resulting large > > footprint, not the cost of the allocation. > > 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.