On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski <z...@php.net> wrote: > On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebast...@php.net> > wrote: > > > Am 31.01.2019 um 18:08 schrieb Derick Rethans: > > > I do not believe that something major like this should make it into any > > > PHP 7.x release. Having it as experimental new feature in the > master/PHP > > > 8.0 branch makes the most sense to me. > > > > ACK > > > > Does it mean that when PHP 8.0 comes out (in roughly two years' time most > probably), we'd be saying this is experimental? Or that only in the > meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before > it's released, we'd say it's experimental but will remove that tag by the > time 8.0 is released? >
I don't think we can really answer that question at this point in time. That depends on how stable and compatible the JIT is by the time PHP 8.0 comes around. But having it as a non-experimental feature should definitely the goal, and I also think this is possible. > If it's the former - I don't think we should go in this direction. If we > decide that it's sensible to have it - I think we should work to ensure > that it's production ready by the time PHP 8.0 is released. Offering it as > something experimental (i.e. not for production) in 7.4 can help us with > that goal, as it will make it easier for a wider range of people to > experiment with it and provide feedback. I can't think of any > technological downsides to including it as experimental in 7.4 - there's a > slight "marketing" downside (it will be less of a shiny new thing in PHP > 8.0), but personally I think the feedback we're likely to get is worth it. > There a number of downsides to including it in PHP 7.4: * First and foremost for me: Maintenance. We are only shortly after branching, and the PHP 7.4 and PHP 8.0 branches already have some significant divergences (e.g. in object handler APIs). I don't expect that this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would also very much prefer not having to maintain a new large and complex chunk of code against two different major engine versions. * Marketing: As you already mentioned yourself, adding a JIT is a great marketing point. I think that PHP 7 was quite successful from a marketing perspective, because it had a nice blend of major performance wins, some long-awaited features and a few incompatibilities. It would be great if we could repeat this with PHP 8, and I think that having a JIT and some major language feature (say generics) would be a great drive to upgrade. Adding the JIT earlier as an experimental feature would dilute this a lot. * Stability / Compatibility: While we can mark features as experimental all we want, let's fact it: If it exists, it's going to end up in production. I would prefer to only publicize the JIT once it is stable, and also importantly, has good integration with 3rd party extensions. Basically "just works". I know that Joe has been testing some of this exts (like pcov and pthreads) and their interaction with the JIT, and also been talking to some other maintainers of "low-level" extensions like profilers. From what I understood, quite some work will be needed to allow integration (beyond just disabling the JIT). Nikita
