Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65159
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.212.48 cause and error)
Message-ID: <51024016.4010005@lerdorf.com>
Date: Fri, 25 Jan 2013 00:19:34 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ralf Lang <lang@b1-systems.de>
CC: internals@lists.php.net
References: <slrnkg3ag2.g88.dsp@experimentalworks.net> <CAJW__o2gncnxnAGd7M7jZjxGADzt2D9xYQOyhp_797Lebx5JSA@mail.gmail.com> <CAL+t6cH6b290+T9=dLp_FFaFCAUiJumx9zvWQNiUr5KfKyunXQ@mail.gmail.com> <51023AB1.2010607@b1-systems.de>
In-Reply-To: <51023AB1.2010607@b1-systems.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 01/24/2013 11:56 PM, Ralf Lang wrote:
>> From what I understood from Rasmus the biggest challenge with merging APC
>> into core is the fact that the compiler currently isn't built to support
>> opcode caching. One of the challenges he pointed out was some of the
>> MAKE_NOP trickery that can make APC's work a bit more complex than
>> necessary. It's possible to optimize the compiler enough to the point that
>> APC's code could be reduced down to very simple opcode caching, putting
>> less stress on the engine and making it easier to maintain.
> 
> I think there was some support for moving APC first from pecl to the PHP
> standard distribution's ext folder before any tighter integration is
> started.

I'm really not convinced that by moving it to core we will magically get
people to help with it. I have been trying to get people interested for
years, and it hasn't gotten very far. Everyone wants it in the core, but
with a couple of exceptions, nobody is willing to actually work on it to
get it there.

And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.

So the learning curve is steep and the bugs are extremely hard to track
down because it is the only PHP component that isn't a perfect sandbox.
A slight memory corruption almost anywhere in any extension can segfault
a dozen requests later with a backtrace that points to the opcode cache
code. Not to mention web servers like Apache that longjmp() on us at the
wrong time. Zend-signals addresses this, but even in 5.4 they aren't
enabled by default because of stability issues and without those no
shared memory opcode cache is safe.

I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.

One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.

-Rasmus