Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain Opus1.COM designates 192.245.12.8 as permitted sender)
Date: Mon, 03 Dec 2007 22:06:19 -0800
In-reply-to: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net>
To: Andi Gutmans <andi@zend.com>
Cc: internals@lists.php.net
Message-ID: <B2740BB0-5215-4018-BEFA-41FC123C81C5@opus1.com>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7bit
References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net>
Subject: Re: [PHP-DEV] Garbage collector patch
From: ron@Opus1.COM (Ronald Chmara)


On Dec 3, 2007, at 1:01 PM, Andi Gutmans wrote:

> Hi all,
>
> Was hoping to send this off earlier but I was travelling for the past
> week and had very limited email access.
>
> As promised in the past few weeks we have spent a significant  
> amount of
> time in reviewing the garbage collector work and testing it in our
> performance lab. Dmitry has been exchanging ideas and patches with  
> David
> Wang during this time. Suffice to say that as I've mentioned in the
> past, memory management is an extremely sensitive piece of PHP,  
> which is
> why it was important for us to review this work in great depth before
> committing it to the code base.
>
> The updated patch still retains the same algorithm as David's original
> implementation however the data structures have been changed in  
> order to
> work faster and use less memory.
> ...
> Personally I think the decision should be either in or out. Adding  
> this
> as a compile option is not a good idea as it would create binary
> compatibility issues and would be a pain for the community.
> ...
> The stage is open for ideas/thoughts/suggestions

I'm really hesitant to even *mention* this idea, but....

Could "alternate" memory management systems be made available via  
PECL add-ons, or, more to the point:
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.

-Ronabop