Just two things.

I definitely don't think, I "just made it 100x more complicated".

I hate complication, and trying to make things simpler and more

efficient. This, sometime, involves new more or less isolated subsystems

like optimizer and now JIT. Of course, they look complex, if you are not

experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to

try JIT. Having this possibility in PHP-7.4 would involve broader auditory.

Thanks. Dmitry.

Morning Dmitry,

I told, I'm not going to do any active JIT development at this point.

Why to waste time, if it's not going to be accepted...

At this point, nobody can imagine that PHP 8 will not have a JIT,

there is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed

to making the improvements that everyone wants to see in the interim,

the vote would be more or less a formality, not really necessary at all,

because we all know what will happen.

I cannot stress enough that you would not be wasting your time to

continue developing the JIT. Saying "it's this or nothing" is not a very

productive or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only

active contributors that are qualified to talk about technical aspects

of the JIT, to improve it, to find or fix bugs. You must also understand

that given the time necessary things will change; You are employed, at

least in part, to work on PHP, and nobody else (afaik) except Nikita is:

We have to find time in our weekends and late at night to read things

we're not familiar with at all, I've never been good at assembly myself,

and my knowledge here is lacking. I look forward to improving my

knowledge, I find it exciting, but it will take a long time, many many

weekends and nights, and 7.4 is simply too early. Even Nikita and Bob

are not comfortable enough to make changes right now, but are still

useful. What we're looking at then, is a bus factor of 1, for about the

next year, it may be as high as 3 or 4 by the time 7.4 is actually

released. There's not 1000 people familiar enough with the Zend of today

to find, fix and improve PHP, but 3 or 4 is just unreasonably low - this

is the reason I say it's dangerous. My words are not meant to be toxic,

at all.

For the last two and a bit years, I've been focused on being a release

manager, and haven't spent a lot of time working on patches like I used

too, I'm still familiar with zend at a low level, but you've just made

it 100x more complicated, and are twisting our arms to accept this

additional complexity, all the while saying you won't make improvements

and don't have time for other improvements that you've identified that

would widen the scope of the JIT considerably (ZTS), and lay the

groundwork for supporting other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and

regardless of whether you intend to disable the JIT by default, it's

going to be rolled out into production in whatever version of PHP it is

merged into, if what it is merged into is a production release of PHP,

you can't stop that with a configure switch or an INI setting, as has

already been pointed out by Nikita. Therefore, it's important that the

JIT is actually production ready and has a scope wide enough to justify

the additional complexity it brings to everything. I'm aware that you

think switching the JIT off is a solution to the tooling problems we

clearly have, but it is not a solution, people are going to expect their

tools to work with it, and saying "disable the JIT" or "disable opcache"

to end users is unacceptable. I realise you have more important things

to do right now than to concentrate on the issues that extension

maintainers have, but it's obvious that these issues need to be

addressed before we push the JIT onto the ecosystem. By withdrawing the

suggestion of merging into 7.4, and focusing our efforts on a really

great PHP 8, you give yourself and all those maintainers time to work

together and find solutions to these problems that are acceptable to us

all, time we all desperately need. yourself included. You also reduce

your own workload considerably by not having to concentrate on 7.4. You

also take away the worry of another unstable release in the 7 series,

which we cannot really afford to have if we don't want to damage

adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the

master branch, this is the best idea I have heard around deploying the

JIT to the world, those releases need not have a fixed schedule and in

no sense are production releases of PHP. I'll happily volunteer myself

to do that additional work and manage those releases while the 7.4

release managers concentrate on a stable 7.4, I'm quite sure that past

release managers will help me there too. We can then nominate permanent

managers for 8 as normal, and I/we will hand over to them a reasonably

stable, well tested JIT, that many of us are comfortable diagnosing and

pushing forward.

If you are interested in ZTS, you may invest time in implementation of

the ZTS improvement idea and then I adopt the JIT in few-days. Tell me

if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was

myself that prepared for PHP 7 the original native-tls patch that was

proposed some time ago for PHP 5, subsequently Anatol had to do all the

heavy lifting, I understand it very well, but I'm not able to

confidently develop on Windows, just like you, I'm not that familiar

with Windows. Again, fixing these things are going to take time, and the

effort of many of us.

Time and commitment, is all I am asking for, without those my confidence

has evaporated, I'm sorry to say.

Cheers

Joe

On Fri, 15 Feb 2019 at 09:06, Dmitry Stogov <[email protected]

mailto:[email protected]> wrote: