Re: Garbage collector patch

On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote:

-----Original Message----- From: Ronald Chmara [mailto:ron@Opus1.COM] What is the *actual cost and complexity* involved in implementing (possibly many) different user-selectable memory management systems, and what other future benefits/drawbacks might we see by doing such a thing? (GC is big now, but what about memory pools per mod_auth user, or SHM/SEM pools, or tuning amounts of memory per function, etc...) I will now apologize to everybody who I just made cry, scream, or damage their furniture, as I didn't mean to hurt you, just trying to stimulate ideas.

Hi Ronald, PHP 5.2.x already supports the ability to hook in different "page" managers. In PHP 5.3 you can also override the memory allocation functions. However, this would not include garbage collection like algorithms which actually require changes in the core PHP data type such as zvals. In fact the garbage collection adds memory to the basic datatypes which is why I suggested to either always make these changes, or don't make them so that we retain binary compatibility across all builds of PHP. So overriding basic memory allocation functions, yes, ability to provide various GC implementations, no.

Okay, so, without this patch, I can allocate mem, and destroy it, on a per page level, but not on a zval level, and the choice is: a) zval (etc.) destruction with this patch, which has a 5% speed hit at times (varies per test) b) no patch, no change c) something which hasn't been thought of yet? I'd have to (sadly) ask that anything that slows down PHP by 5%, to improve performance for programmers that, uhm, "leak" or otherwise gobble RAM, that they, uhm, refactor their code as professional programmers. Thanks for clearing it up for me, Andi. -Bop