Date: Sun, 24 Feb 2013 17:50:34 -0600 From: Stephen Montgomery-Smith <stephen@missouri.edu> To: Ian Lepore <ian@FreeBSD.org> Cc: Jeremy Chadwick <jdc@koitsu.org>, Michael Ross <gmx@ross.cx>, freebsd-stable@FreeBSD.org, John Mehr <jcm@visi.com> Subject: Re: svn - but smaller? Message-ID: <512AA74A.4060708@missouri.edu> In-Reply-To: <1361749413.16937.16.camel@revolution.hippie.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> <1361749413.16937.16.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/24/2013 05:43 PM, Ian Lepore wrote: > 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. I think that the stacksize and datasize cannot together add up to more than 4G, or maybe it is only 2G, at least on a 32 bit machine. This is because (I think) they compete for virtual memory address space. I guess this wasn't a problem in the old days, when 4G of RAM was unthinkable. Also, as I said in another thread, I think Linux doesn't make this distinction. So at least someone else out there agrees with you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512AA74A.4060708>