From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 21:24:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C8906AB for ; Sun, 24 Feb 2013 21:24:38 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id C018C6BE for ; Sun, 24 Feb 2013 21:24:37 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 4M1e1l0031HpZEsA2MQd65; Sun, 24 Feb 2013 21:24:37 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 4MQc1l00S1t3BNj8aMQcCa; Sun, 24 Feb 2013 21:24:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 72A0473A1C; Sun, 24 Feb 2013 13:24:36 -0800 (PST) Date: Sun, 24 Feb 2013 13:24:36 -0800 From: Jeremy Chadwick To: Ian Lepore Subject: Re: svn - but smaller? Message-ID: <20130224212436.GA13670@icarus.home.lan> References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1361726397.16937.4.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361741077; bh=QteblBxRs7Hgkgex2XhmViQJrDsDuXwI6cppvX2T4Qs=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=BYhMuXPS+iJTGXKhVLyyWKwWIdo4cWUhvb2HyWPQPbFLQH/TpPSnfxHA7gArOFi31 kL7vrrWW+baIkI6GJiiHumbCpxyQOm7TncTZ3KRKcysnpzI/y7ZXTOcrrMTIKQjmW6 A/wAXXHlvSvx/cSpDsL3VeKy3mxoDRVT0aw2hQ/7B4fviWSUmAWBZMxEDVk4bneaWH iLzt2qeFOun/yeEr/cgMMpxNMaF5yLfuY/o/pjBgrYb0BrXadmVmbZjKadHtUUnpYn LgN54ek7UFML64BMTWnvlo1hk4zxt6zMrv6CUkJqNbcos+8cA6vvY0WEBKXJF0S0j4 1SAF5QV7Rvzgw== Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 21:24:38 -0000 On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > bytes). I'm referring to this: > > Why? I absolutely do not understand why people are always objecting to > large stack-allocated arrays in userland code (sometimes with the > definition of "large" being as small as 2k for some folks). This is incredibly off-topic, but I'll bite. I should not have said "heap-allocated", I was actually referring to statically-allocated. The issues as I see them: 1. Such buffers exist during the entire program's lifetime even if they aren't actively used/needed by the program. With malloc(3) and friends, you're allocating memory dynamically, and you can free(3) when done with it, rather than just having a gigantic portion of memory allocated sitting around potentially doing nothing. 2. If the length of the buffer exceeds the amount of stack space available at the time, the program will run but the behaviour is unknown (I know that on FreeBSD if it exceeds "stacksize" per resource limits, the program segfaults at runtime). With malloc and friends you can gracefully handle allocation failures. 3. Statically-allocated buffers can't grow; meaning what you've requested size-wise is all you get. Compare this to something that's dynamic -- think a linked list containing pointers to malloc'd memory, which can even be realloc(3)'d if needed. The definition of what's "too large" is up to the individual and the limits of the underlying application. For some people, sure, anything larger than 2048 might warrant use of malloc. I tend to use malloc for anything larger than 4096. That "magic number" comes from some piece of information I was told long ago about what size pages malloc internally uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it appears to be a lot more complex than that. If you want me to break down #1 for you with some real-world output and a very small C program, showing you the effects on RES/RSS and SIZE/VIRT of static vs. dynamic allocation, just ask. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |