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: Enlarge MAX_ALLOCA? Date: Thu, 19 Jun 2014 19:02:43 +0300 Message-ID: <83sin0sx98.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403193813 22274 80.91.229.3 (19 Jun 2014 16:03:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Jun 2014 16:03:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 19 18:03:27 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 1Wxeo7-0000pI-S6 for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 18:03:23 +0200 Original-Received: from localhost ([::1]:36568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxeo5-0004Fg-9r for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 12:03:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxenu-0004EP-LG for emacs-devel@gnu.org; Thu, 19 Jun 2014 12:03:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wxenk-0003qB-4T for emacs-devel@gnu.org; Thu, 19 Jun 2014 12:03:10 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxenj-0003pd-ST for emacs-devel@gnu.org; Thu, 19 Jun 2014 12:03:00 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N7F00900B3MXE00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 19 Jun 2014 19:02:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7F0098FB8XUZ50@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 19 Jun 2014 19:02:58 +0300 (IDT) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:172534 Archived-At: Does anyone see problems with the change below, which raises the bar for 'alloca' to 64KB? Are there any systems out there that we care about whose stack is so small as to make this dangerous? Why 64KB? Because that's the size of the work area coding.c allocates whenever it needs to encode or decode something. It turns out we do this a lot, e.g., every redisplay calls file-readable-p on the icon image files, which needs to encode the file name. While the work area is immediately free'd, I think allocating such a large buffer so much has a potential of creating an unnecessary memory pressure on 'malloc', and perhaps cause excess fragmentation and/or enlarge memory footprint in some cases. Thoughts? === modified file 'src/lisp.h' --- src/lisp.h 2014-06-17 16:09:19 +0000 +++ src/lisp.h 2014-06-19 15:37:17 +0000 @@ -4425,7 +4425,7 @@ extern void init_system_name (void); /* SAFE_ALLOCA normally allocates memory on the stack, but if size is larger than MAX_ALLOCA, use xmalloc to avoid overflowing the stack. */ -enum MAX_ALLOCA { MAX_ALLOCA = 16 * 1024 }; +enum MAX_ALLOCA { MAX_ALLOCA = 64 * 1024 }; extern void *record_xmalloc (size_t) ATTRIBUTE_ALLOC_SIZE ((1)); @@ -4434,7 +4434,7 @@ extern void *record_xmalloc (size_t) ATT /* SAFE_ALLOCA allocates a simple buffer. */ -#define SAFE_ALLOCA(size) ((size) < MAX_ALLOCA \ +#define SAFE_ALLOCA(size) ((size) <= MAX_ALLOCA \ ? alloca (size) \ : (sa_must_free = true, record_xmalloc (size))) @@ -4469,7 +4469,7 @@ extern void *record_xmalloc (size_t) ATT #define SAFE_ALLOCA_LISP(buf, nelt) \ do { \ - if ((nelt) < MAX_ALLOCA / word_size) \ + if ((nelt) <= MAX_ALLOCA / word_size) \ (buf) = alloca ((nelt) * word_size); \ else if ((nelt) < min (PTRDIFF_MAX, SIZE_MAX) / word_size) \ { \