Date: Sun, 24 Feb 2013 16:43:33 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Jeremy Chadwick <jdc@koitsu.org> Cc: Michael Ross <gmx@ross.cx>, freebsd-stable@FreeBSD.org, John Mehr <jcm@visi.com> Subject: Re: svn - but smaller? Message-ID: <1361749413.16937.16.camel@revolution.hippie.lan> In-Reply-To: <20130224212436.GA13670@icarus.home.lan> References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <web-10502111@mailback3.g2host.com> <web-12014638@mailback4.g2host.com> <op.wszomvfyg7njmm@michael-think> <20130224031509.GA47838@icarus.home.lan> <op.wszrv9k5g7njmm@michael-think> <20130224041638.GA51493@icarus.home.lan> <op.wszt3wh2g7njmm@michael-think> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > 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. > Actually, after seeing that the userland limit for an unpriveleged user on freebsd is a mere 64k, I'd say the only valid reason to not allocate big things on the stack is because freebsd has completely broken defaults. I see no reason why there should even be a distinction between stack size and memory use limits in general. Pages are pages, it really doesn't matter what part of your virtual address space they live in. Almost everything I've ever done with freebsd runs as root on an embedded system, so I'm not used to thinking in terms of limits at all. -- Ian [P.S. Having mail troubles today, sorry if this gets duplicated.]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1361749413.16937.16.camel>