Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <4892FB94.5030107@zend.com>
Date: Fri, 01 Aug 2008 16:03:32 +0400
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Stefan Esser <stefan.esser@sektioneins.de>
CC: Marcus Boerger <helly@php.net>, 
 PHP Internals List <internals@lists.php.net>
References: <4890CC7A.6060303@sektioneins.de> <416879664.20080801004706@marcus-boerger.de> <4892F46A.1060008@zend.com> <4892F813.6050402@sektioneins.de>
In-Reply-To: <4892F813.6050402@sektioneins.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Switch Table Extension for PHP
From: dmitry@zend.com (Dmitry Stogov)

Hi Stefan,

Opcode caches don't usually copy the op_array.opcodes from shared memory
to process memory, so modification of opcodes may affect other processes
which execute the same op_array.

As you set the extended_value in shared memory to point into process
memory the other process will read it and look into it's own memory, and
of course it won't find proper switch-table there.

It makes sense to do this optimization before storing op_array in shared
memory (in PHP compiler itself or optimizer).

Thanks. Dmitry.

Stefan Esser wrote:
> Hello Dmitry,
> 
> while I also believe that the extension should not be included in the
> core at the moment I strongly believe that it will be compatible with
> every well behaving opcode cache.
> 
> Because it modifies op_array during execution...
> a) the opcode cache is not affected at all because it always provides a
> copy of the cached op_array to execute()
> 
> or b) the modification will be performed on the cached opcodes in memory
>  which means the opcode cache either stores (and therefore shares) the
> manipulated opcodes (with other processes) or not. Either way any
> process loading the opcodes that were manipulated by another process
> should recognise the loaded op_array as not yet optimized. Therefore the
> optimization will be repeated in the other process again => No problem
> at all.
> 
> Therefore only on edge cases, where 2 processes share the same memory
> addresses for the switchtables a malfunction due to an opcode cache can
> happen. (I will improve that by a canary value that is different for
> each process and that I will store in the extented_value of the JMPZ
> opcode that is following the CASE)
> 
> Attention: switchtable is not threadsafe at the moment
> 
> 
> Stefan Esser