[PATCH] Memory problem.

Some people have mentioned having problems where idle PHP processes hang around without freeing their memory (in a FastCGI or Apache module modes). As I have found, it's not really a memory fragmentation problem. The core of the problem is the fact, that free() doesn't return memory to the OS immediately. So, if we have memory hungry PHP scripts and use PHP in a FastCGI or Apache module environment, then large amount of memory could still remain allocated for a process while it's waiting for the next HTTP request. Attached is a patch which resolves this problem by forcing the memory allocator to return free pages to the operating system at the end of the request. Especially in instances where some of your PHP scripts use a lot of memory, this maybe be quite useful in reducing the machine's overall memory consumption at a given time. I think it's probably best for this explicit memory collector mode not to be used in the multithreaded environment (for performance reasons), but the patch works properly if ZTS is enabled. Two new configuration variables could be set in a php.ini: memory_trim_limit (default is 1M) - is a minimum memory grow per request limit until malloc_trim mechanism will be invoked. "0" value disables it. memory_grow_limit (default is 128M) - is a memory grow limit. If process reaches it, then force_exit SAPI global is turned on and could be used in SAPI modules to force process exit. This is for the case when we have persistent objects on the top of memory or memory leaks in external libraries. "0" value disables it. Patch also includes processing of force_exit SAPI global for CGI SAPI module (for FastCGI mode), Apache SAPI module and Apache 2.0 Handler SAPI module (for prefork Apache2 mode). Please review it, try it and send me feedback. With best regards, Alexander Veremyev.