From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Enlarge MAX_ALLOCA? Date: Thu, 19 Jun 2014 19:04:09 +0200 Message-ID: <877g4c96gm.fsf@fencepost.gnu.org> References: <83sin0sx98.fsf@gnu.org> <87bnto98ch.fsf@fencepost.gnu.org> <83r42ksv5l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403197486 3754 80.91.229.3 (19 Jun 2014 17:04:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Jun 2014 17:04:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 19 19:04:39 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 1WxflO-0004Lg-0V for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 19:04:38 +0200 Original-Received: from localhost ([::1]:36799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxflN-00007k-J5 for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 13:04:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxflI-0008VT-7T for emacs-devel@gnu.org; Thu, 19 Jun 2014 13:04:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxflH-0001zq-2u for emacs-devel@gnu.org; Thu, 19 Jun 2014 13:04:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxflG-0001zf-Td for emacs-devel@gnu.org; Thu, 19 Jun 2014 13:04:31 -0400 Original-Received: from localhost ([127.0.0.1]:58678 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxflF-0000x7-Uc; Thu, 19 Jun 2014 13:04:30 -0400 Original-Received: by lola (Postfix, from userid 1000) id 92B88E086B; Thu, 19 Jun 2014 19:04:09 +0200 (CEST) In-Reply-To: <83r42ksv5l.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 19 Jun 2014 19:48:06 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:172537 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Thu, 19 Jun 2014 18:23:26 +0200 >> >> Eli Zaretskii writes: >> >> > -#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) \ >> > { \ >> >> Bad idea to change < to <= here. > > The original macros were inconsistent: some used < and some <=, so I > changed them. > >> If there is a hard limit due to short offsets or similar (and if >> there weren't, why bother at all?), then allocating a full 64kB >> might be a bad idea. > > Is there really such a system? If so, which one? Either your limit has a rationale in machine architectures or not. If it has: the C standard guarantees that you are allowed to take the address _after_ an array. The 68k architecture has short offsets (-32768..+32767) for addressing off an address register such as the stack pointer. > And why would that be a worse idea than to allocate the same 64KB off > the heap (which is what that macro does in the 'else' clause? What am > I missing? Heap addressing will not employ short offsets/pointers on such architectures. >> 64kB feels arbitrary. > > I explained my rationale for choosing this value. The explanation was: > 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. That's not related to an architecture restraint. In fact, it merely follows the arbitrary definition #define CHARBUF_SIZE 0x4000 Arbitrary because this is not a lookup table size but a buffer size for portioned conversion. Instead of doubling MAX_ALLOCA, it would seem to make more sense to reduce CHARBUF_SIZE to something making it fit better on the stack if this is performance relevant. As I said: there are architectural reasons (short addressing mode) making somewhat less than 32kB a good choice on some architectures. -- David Kastrup