On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote: > If "what it does" is merely return the value of the C sbrk() function, > then IMHO, sbrk() is a perfectly good name. > > However, as to other possible names -- how about ProcessSize() ? I'm > not sure if this is really a valid description of what sbrk() returns, > though.
I'm not certain it's as accurate as we might like to think. I am under the impression (quite possibly wrong, as I don't have the source code handy) that 1: Doug Lea's malloc will do anonymous mmap() to satisfy really big requests 2: glib malloc is a variant derived from Doug Lea's code Hence is it plausible that systems exist where the malloc that perl calls may normally get memory from the system with sbrk(), but occasionally use somewhere other than the system heap. So perl code might cause more memory to be used, but if we report back sbrk() as process size we're actually claiming a bit more for our "fact" than we can actually be sure of. If we call it sbrk() we can divorce ourselves from actually claiming that it is the one true source of memory :-) Not that this is helpful - I guess we want a direct sbrk() interface if sbrk() is on the system, and a process size interface that makes the best estimate it can. But I'm not writing this thing, and so far I guess I've not wanted it *that* much. [mm. maybe I have. number 3 on my hitlist of "what slows perl" is RAM. So seeing if a data structure change reduces RAM is interesting to me, the encode compiler, and everyone building perl from source] Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
