Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32398
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hardened-php.net from 81.169.159.221 cause and error)
Message-ID: <46F2627F.6060807@hardened-php.net>
Date: Thu, 20 Sep 2007 14:07:27 +0200
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>
Cc: Stefan Esser <stefan.esser@sektioneins.de>,
	PHP internals <internals@lists.php.net>
References: <46F24A61.8050509@sektioneins.de> <alpine.DEB.0.98.0709201339230.29705@kossu.ez.no>
In-Reply-To: <alpine.DEB.0.98.0709201339230.29705@kossu.ez.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Storing additional information for op_arrays
From: sesser@hardened-php.net (Stefan Esser)

Derick Rethans schrieb:
> On Thu, 20 Sep 2007, Stefan Esser wrote:
>
>   
>> One problem I and others have run into is that from time to time we need
>> to store extra information for specific opcode arrays. For simple values
>> it is possible to use one of the reserved slots in the op_array
>> structure, but in the past that has been unrelieable because APC for
>> example simply overwrote the first slots without asking the Zend Engine
>> to reserve some space.
>>     
>
> Have a pointer on how this is done? I sortof need/want to do this in 
> Xdebug as well, however I don't want opcode caches to remember this 
> value.
>   
Well the "official" way to use the reserved area of an opcode array is
to get an handle from the zend engine for reserved space.
This is done by
ZEND_API int zend_get_resource_handle(zend_extension *extension)
it returns an index you can simply use. (I think meanwhile APC will
honor this and will not overwrite the first bytes).

> Sounds like a good idea to me - but the op code caches do need to some 
> special trickery for this I guess. However, in my case I do *not* want 
> an opcode cache to remember the stored data, so that perhaps needs to be 
> taken into account as well
The basic idea would be to add API functions like
zend_op_array_add_data(key, data, size, flags)
zend_op_array_remove_data()... zend_op_array_get_data,
zend_op_array_get_all_data
In the flags one could choose: Needs to be cached etc...

Well and this will be stored in a datastructure that will just be
pointed at by the op_array struct.
So op_arrays will not really grow (just a single pointer added) and the
whole overhead is only in the
extensions that actually require such extra data and in the opcode
caches that need to cache this.

And I think the opcode cachers would just need to traverse the list of
all data and store it with the op_array. I doubt that would take much
changed in the cacher software. And well if the cache authors speak up,
PHP can pretty much implement all the API functions required for such a
step...

Stefan Esser