Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <51024016.4010005@lerdorf.com>
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> <51024016.4010005@lerdorf.com>
Date: Fri, 25 Jan 2013 11:37:21 +0100
Message-ID: <CAMUwpuSNvr3LG4HT0D91wFoF+y0Dc8B9-yCW8YeHL0WALFDWPw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Ralf Lang <lang@b1-systems.de>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307ca38e84179c04d41a8590
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: jpauli@php.net (Julien Pauli)

--20cf307ca38e84179c04d41a8590
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> 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.
>

That feels like a safe idea. I'm convinced that having more internals
documentation will help
developpers understand at least the engine (that's what interest us here).

I know it's a hard task, but we all here have blogs where sometimes we
write great articles
about a part of internals, I think we should focus on working alltogether
writing a real technical doc for the engine,
that will help people (like me for example), understand some dark parts of
it, and then find ideas or solutions for it to
evolve the right way.


> 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.
>

Ok that seems clear.

Julien.Pauli

--20cf307ca38e84179c04d41a8590--