Dan Sugalski <[EMAIL PROTECTED]> writes:
Anyway, if perl's using its own memory allocator you'll want to rebuild it to not do that.
You would need to do that if you wanted to use a debugging malloc. But there's no particular reason to think that you should need to do this just to work properly.
Two mallocs can work fine alongside each other. They each call mmap or sbrk to allocate new pages and they each manage the pages they've received. They won't have any idea why the allocator seems to be skipping pages, but they should be careful not to touch those pages.
Perl will only use a single allocator, so there's not a huge issue there. It's either the external allocator or the internal one, which is for the best since you certainly don't want to be handing back memory to the wrong allocator. That way lies madness and unpleasant core files.
The bigger issue is that perl's memory allocation system, the one you get if you build perl with usemymalloc set to yes, never releases memory back to the system -- once the internal allocator gets a chunk of memory from the system it's held for the duration of the process. This is the right answer in many circumstances, and the allocator's pretty nicely tuned to perl's normal allocation patterns, it's just not really the right thing in a persistent server situation where memory usage bounces up and down. It can happen with the system allocator too, though it's less likely.
One of those engineering tradeoff things, and not much to be done about it really.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
