Re: [PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default

[Dmitry Stogov]

> No problem, I can change the defaults but remove the fatal error if
> jit=non-zero and jit_buffer_size=0, can I still turn it into a warning
> though?
>

I think we don't need the warning. It's clear that JIT won't work with
"opcache.jit_buffer_size=0" in php.ini.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default

[Dmitry Stogov]

Hi Daniil,

Currently JIT may be disabled by setting "opcache.jit=disable" or
"opcache.jit_buffer_size=0".
Many PHP installations have php.ini with the current default settings
"opcache.jit=tracing" and "opcache.jit_buffer_size=0".
After upgrading to the new PHP version with this patch, all of them won't
be able to start PHP.

I don't care a lot about the php.ini defaults, but I don't like to give our
users a headache.

Thanks. Dmitry.





After your patch

On Wed, Nov 15, 2023 at 10:35 PM Daniil Gentili  wrote:

> Hi all,
>
> I would like to submit an RFC and PR to change a few INI defaults for
> opcache, changing how JIT is disabled by default.
>
> Here's the URL of the RFC: https://wiki.php.net/rfc/jit_config_defaults.
>
> I'd more more than glad to receive some feedback!
>
> Regards,
>
> Daniil Gentili.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] Re: [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi,

The vote has ended.
The RFC was accepted by 26 vs 0.
Also, 25 vs 0 voted to remove the old JIT implementation right after
merging the new one.

I'm going to merge the Pull Request next week (on Monday or Tuesday) and
then remove the old JIT implementation in the next few days.
Let me know if someone sees any critical implementation issues.

Thanks. Dmitry.


On Thu, Oct 5, 2023 at 10:52 PM Dmitry Stogov 
wrote:

> Hi internals,
>
> The vote on "A new JIT implementation based on IR Framework" RFC is
> started.
>
> https://wiki.php.net/rfc/jit-ir
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4

[Dmitry Stogov]

On Tue, Oct 17, 2023 at 8:46 PM Daniil Gentili  wrote:

> Hello,
>
> I would like to submit an RFC and PR to change a few INI defaults for
> opcache, changing how JIT is disabled by default.
>
> Currently, JIT is disabled by default using the
> |opcache.jit_buffer_size=0| default, instead of |opcache.jit=0|.
>
> I.e. here are the defaults for these two configuration entries:
>
> - opcache.jit=tracing
> - opcache.jit_buffer_size=0
>
> This effectively disables JIT not because `jit=0`, but rather because
> the buffer size is set to 0.
>
> I would like to change these defaults to:
>
> - opcache.jit=off
> - opcache.jit_buffer_size=64m (taken from
> https://github.com/php/php-src/pull/12425/files, any smaller multiple of
> 2 causes the buffer to fill up when running moderately sized projects
> like Psalm or PHPStan).
>
> What do you think?
>

Actually, now opcache.jit=0/off/no/false doesn't disable JIT completely. It
makes PHP start requests with JIT disabled, but this may be changed during
the request.
JIT may be disabled completely by opcache.jit=disable

Thanks. Dmitry.


>
>
> Kind regards,
>
> Daniil Gentili.
>

Re: [PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

[Dmitry Stogov]

On Fri, Oct 6, 2023 at 10:52 PM Levi Morrison 
wrote:

> On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov 
> wrote:
> >
> > Hi internals,
> >
> > The vote on "A new JIT implementation based on IR Framework" RFC is
> started.
> >
> > https://wiki.php.net/rfc/jit-ir
> >
> > Thanks. Dmitry.
>
> From the RFC:
>
> > The details of the IR framework are complex. This [presentation][1]
> explains design ideas and makes overview of the most important
> implementaion details.
>
> Was this presentation recorded and is it watchable somewhere? It looks
> to have answers to many questions I had
>

The record should be available in a month or two in Russian.

Thanks. Dmitry.


>
>   [1]:
> https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP
>

Re: [PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

[Dmitry Stogov]

On Thu, Oct 5, 2023 at 11:07 PM Tim Düsterhus  wrote:

> Hi
>
> On 10/5/23 21:52, Dmitry Stogov wrote:
> > The vote on "A new JIT implementation based on IR Framework" RFC is
> started.
> >
> > https://wiki.php.net/rfc/jit-ir
>
> One small note: You forgot to adjust the 'Status' at the top of the RFC
> itself. It still specifies 'Under Discussion' instead of Voting.
>

Thanks for pointing it out. Fixed.

Thanks. Dmitry.


>
> Other than that it looks good to me. Thank you!
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi internals,

The vote on "A new JIT implementation based on IR Framework" RFC is started.

https://wiki.php.net/rfc/jit-ir

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi Internals,

I've published a presentation about the IR Framework design and
implementation details.
See
https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP
It explains many complex things in simple pictures.

Thanks. Dmitry.

On Thu, Sep 21, 2023 at 11:26 AM Dmitry Stogov 
wrote:

> Hi Internals,
>
> After all the Poll Request discussions (see
> https://github.com/php/php-src/pull/12079), code-reviews and internal
> discussions with core developers we decided to move this through the RFC
> process.
>
> Thanks to all participants.
>
> The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi Deleu,

On Thu, Sep 21, 2023 at 12:31 PM Deleu  wrote:

>
>
> On Thu, Sep 21, 2023 at 6:13 AM Tim Düsterhus  wrote:
>
>> Hi
>>
>> On 9/21/23 10:26, Dmitry Stogov wrote:
>> My understanding is that even if the new JIT might not (yet) be better
>> than the old one, it is not worse and it is more maintainable. The
>> reactions from more knowledgeable folks were pretty positive overall.
>>
>> So if the new JIT passes the existing test suite without issues, I don't
>> see a reason why the old JIT should not be replaced right away. By
>> immediately removing the old JIT (ideally in a separate commit) the
>> codebase is cleaned up and users that want to test PHP 8.4 (or whatever
>> that version may be in the end) will be forced to also test the new JIT
>> which is probably a good thing.
>>
>
> If I understand correctly, the only way to fallback to the JIT 1.0
> implementation is by compiling PHP with a new introduced flag, so the JIT
> 2.0 needs to be opt-out. The RFC doesn't mention the configurations for new
> JIT (init settings) which makes me assume that they're exactly the same? If
> these assumptions are right, I think the matter of keeping or removing JIT
> 1.0 implementation is mostly a matter of what makes Dmitry more
> comfortable. Removing it straight-away might result in adding more pressure
> in getting bug fixes on the new one, while keeping it might make it
> possible for whoever is relying heavily on JIT to still compile new PHP
> releases with JIT 1.0 to give more time to iron out the final details on
> JIT 2.0.
>

In the current state the Pull Request starts using the new JIT
implementation by default, but keeps the old implementation.
It's a question, if we need to keep it for a while or remove it immediately.
Now I think it's going to be removed in PR/RFC before starting the voting.


> Of course this is a very basic analysis on my part which mixes my
> experience in replacing PHP running-systems with new rewrites and it's much
> more comfortable to me to have a fallback mechanism in place which may or
> may not be entirely relevant here.
>

Keeping the disabled old JIT, we won't test it anyway and this won't
guarantee anything.
In case the new JIT will cause really serious problems we may consider
reverting it.

Thanks. Dmitry
.

>
> --
> Marco Deleu
>

Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi Sebastian,

On Thu, Sep 21, 2023 at 12:22 PM Sebastian Bergmann 
wrote:

> Am 21.09.2023 um 11:13 schrieb Tim Düsterhus:
> > Thank you. I find it important to follow the formal process, even if
> many
> > folks are not able to make a meaningful decision due to the lack of
> > knowledge about the topic. This includes me.
>
> I'm in the same boat.
>
> > My understanding is that even if the new JIT might not (yet) be better
> > than the old one, it is not worse and it is more maintainable. The
> > reactions from more knowledgeable folks were pretty positive overall.
>
> That is my understanding as well.
>
> > So if the new JIT passes the existing test suite without issues, I don't
> > see a reason why the old JIT should not be replaced right away. By
> > immediately removing the old JIT (ideally in a separate commit) the
> > codebase is cleaned up and users that want to test PHP 8.4 (or whatever
> > that version may be in the end) will be forced to also test the new JIT
> > which is probably a good thing.
>
> I agree.
>
> As a sidenote: most of the teams that I work with use PHP 8 in production.
> However, none of them use the current JIT. It either caused problems
> (especially during early PHP 8.0 versions), or does not bring any
> significant performance improvement. Against that backdrop, I would be
> interested in whether you, Dmitry or Zend, can share some insight from
> real-world usage of the JIT.
>

I still don't recommend using JIT for production without serious testing
and benchmarking for each concrete case.
If you see less than 5% speedup - you probably don't need JIT; if an AMPHP
bsed server becomes 1.5 times faster it's a different story.

Thanks. Dmitry.


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi Tim.

On Thu, Sep 21, 2023 at 12:13 PM Tim Düsterhus  wrote:

> Hi
>
> On 9/21/23 10:26, Dmitry Stogov wrote:
> > After all the Poll Request discussions (see
> > https://github.com/php/php-src/pull/12079), code-reviews and internal
> > discussions with core developers we decided to move this through the RFC
> > process.
> >
> > Thanks to all participants.
> >
> > The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir
>
> Thank you. I find it important to follow the formal process, even if
> many folks are not able to make a meaningful decision due to the lack of
> knowledge about the topic. This includes me.
>
> That said, I'd like to add my two cents to the "Open Issues" section:
>
> My understanding is that even if the new JIT might not (yet) be better
> than the old one, it is not worse and it is more maintainable. The
> reactions from more knowledgeable folks were pretty positive overall.
>
> So if the new JIT passes the existing test suite without issues,


Passing test suites doesn't mean we couldn't have other problems.


> I don't
> see a reason why the old JIT should not be replaced right away. By
> immediately removing the old JIT (ideally in a separate commit)
>

I'm going to agree to remove the old JIT and I like the idea of removing it
in a separate commit.

Thanks. Dmitry.


>
> Best regards
> Tim Düsterhus
>

[PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

[Dmitry Stogov]

Hi Internals,

After all the Poll Request discussions (see
https://github.com/php/php-src/pull/12079), code-reviews and internal
discussions with core developers we decided to move this through the RFC
process.

Thanks to all participants.

The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

On Sat, Sep 16, 2023 at 12:46 PM Hans Henrik Bergan 
wrote:

> I think the submodule approach is fine, but maybe it should be moved from
> Dmitry's gh to php-src gh, or maybe it's own dedicated group, to reduce the
> bus factor (how much work needs to be done if Dmitry is hit by a bus~)
>

``git submodules``are useful for development, but I'm not sure about the
problems that they may make for maintainability.
Imagine, we have few different php versions that use different versions of
IR, then we have to backport patches and maintain different versions of the
IR, etc

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

On Sat, Sep 16, 2023 at 1:22 AM Tim Düsterhus  wrote:

> Hi
>
> On 9/15/23 17:50, Ben Ramsey wrote:
> > Additionally, despite the use of a Git submodule complicating things for
> > "everyone else," it provides a clear dependency and development
> > boundary, avoiding situations where the php-src version of IR drifts
> > from the upstream version. I think we can adjust tooling and messaging
> > to help folks know how to use the submodule. :-)
>
> Do not want: If the submodule repository goes away for whatever reason,
> the dependency will no longer be available. IR is currently sitting in
> Dmitry's personal GitHub account and it would not be the first time that
> a GitHub account is suspended for good or less good reasons [1].
>

Yes. I agree. Everything is possible nowadays.


> Bundle IR in some dedicated directory with php-src. Then updating it is
> as easy as "throw away the directory and copy over the new files". We
> could even automate that using GitHub actions to sync in the changes
> every night or so.
>

I already embedded the necessary part of the IR project unde
``/ext/opcache/jit/ir``.
I'm going to manage mirroring manually (similar to libdate in ext/date).

Dmitry also said that he gave 'git subtree' a try. I don't know that
> command myself, but it looks exactly like what is required here. I would
> be interested in hearing whyy it didn't work well.
>

``git subtree`` and ``subrepo`` may help mirroring but they are also not
ideal.
On one hand they can't mirror the history in a useful way, on the other
hand they can't mirror part of the project.

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

On Mon, Sep 18, 2023 at 8:01 AM Pierre Joye  wrote:

> Great work! This is a massive jump for PHP. Thank you :)
>
> I don't have much concerns about the license etc as the ZE is already
> under Zend the ZE license (never updated since Perforce acquired them,
> tho'):
>
> https://github.com/php/php-src/blob/master/Zend/LICENSE
>
> I do really like the IR addition. This opens huge new opportunity, not
> only for optimization and JIT but to move forward into bringing new
> technology support to PHP (WASM f.e.). There are big challenges and I
> am not sure yet it can be ever be fully possible to target WASM.
>

Creating a new back-end for IR is significantly simpler than for old
PHP-JIT implementation.
However, I'm not sure if this will work for WASM, because PHP-JIT calls a
lot of functions from PHP itself.
I'm not sure how this should work with WASM. I just didn't research in this
area.


> however, having the ability to do it with a subset of PHP, f.e. some
> business logic classes etc., would already be amazing. I can't imagine
> a php9 without taking this into account tbh. That would be kill php in
> any way but that would definitively puts it in less competitive area
> than others (JS, go, rust, ocaml f.e.), for another few years.
>
> I have a simple php function working (just a small go app to parse the
> IR text output and convert it. But that's not remotely a POC :).


Really? You already use the IR Framework? :)


> I discussed with Dmitry and the idea would be to add a WASM target to
> libIR (partial support or whatever is possible).
>
> This is the part I would like to see more discussions or feedback as
> it will define what could become possible or not. A certain level of
> similarity or compatibility could make other targets much easier.
>
> > The old JIT implementation is going to be kept for a while.
>
> I like the idea too. The sooner this work can be available as
> experimental, the sooner it will get stable.
>


Yes. I hope it's already quite stable. It passes all the nightly CI tests,
including Amp, Symfony, Laravel and Wordpress uit tests.
But it definitely will cause problems. The sooner we start the more time we
will have to release.
And keeping the old version for a while, we have a plan B.

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

Hi Ben,

On Fri, Sep 15, 2023 at 6:50 PM Ben Ramsey  wrote:

> On 9/15/23 09:35, Derick Rethans wrote:
>
> > I understand that working on an RFC for such a complex issue is going to
> > take time, but that also gives to opportunity to pair with somebody,
> > who, while writing it, will also learn how it works. That would also
> > ready improve the debugging/contributing issues.
>
> +1, this needs an RFC, if only to help articulate and explain how it
> works, as Derick says. I'd love to volunteer to help with the RFC, but
> I'm already stretched thin, as it is.
>

As I said, I'm going to publish a presentation (in October).
I'm not sure if we should have an RFC that will repeat it.
Anyway, if you like to understand how PHP-JIT-IR works and explain this to
others, I would appreciate this.
I'm ready to answer any questions.


> A few things I noted while looking through the code in the IR repository...
>
> It looks like the goal of the project is for IR to provide JIT
> compilation for other projects. Do you already have some idea where
> (other than php-src) it will be used? Is it already being used elsewhere?
>

Pierre thinks about WASM backend.
I like to write a C front-end and something similar to Truffle.


> IR is currently on your personal GitHub account, but the copyright
> listed on the license is for "Zend by Perforce," while other source
> files (e.g., ir_cpuinfo.c) list "IR project" as the copyright holder. I
> assume this is because you (Dmitry) have been working on this on Zend's
> time, while other contributors have been working on it independently.
> Who is the ultimate owner/controller of the project? If it's a Zend by
> Perforce project, what's their goal for it? (I'm not asking because I
> think there are hidden agendas; I'm just curious what the plans are for
> long-ish term support of IR.)
>
> Noted that the license on IR is MIT. Love it!
>

The IR project was developed under the  "Zend by Perforce" umbrella.
It paid for development, it has the copyright, but we choose the most
permissive license.
The main goal is the improvement of PHP, but we also like to involve
non-PHP experts.

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

Hi Derick,

On Fri, Sep 15, 2023 at 5:35 PM Derick Rethans  wrote:

> I think this is great work. It looks like the new JIT-IR approach is
> more suitable. I have however concerns with a few things here.
>
> This is a lot of new code, that very few other people understand in
> great detail.
>
> I think it is unwise if we have another large part of the engine that
> does not have enough people understanding enough of it, to be able to
> debug issues, and contribute to its continued development.
>

The IR Framework project is going to be developed separately from PHP.
Ideally this project will involve compiler experts from different areas.
I'm doing my best in this direction.


> As such, I don't think this should just be merged, without a
> comprehensive document explaining what it is, how it works, what pitfalls
> there are, etc.


In the mid of October I'll speak about IR at a Java related conference.
Then I'll make available a presentation that explains many internals of the
IR Framework.


> The natural process that we have for PHP would be to
> create an RFC.
>

I'm not sure. The PR just adds a different way to generate native code.
Instead of existing ``zend_jit_x86.dasc`` and ``zend_jit_arm64.dasc`` where
we had to write assembler code manually, now we have a single
``zend_jit_ir.c`` where we have to construct the IR graph. Disassembler,
Linux perf interface and other low-level JIT details were also moved to JIT
framework. So, actually the PHP part becomes even simple.


> An RFC should also include a user-facing API on how to configure, and
> enable, the JIT and its optimisations, as our current implementation
> it is not the most convenient for users.
>

Nothing has changed. The new JIT is a completely self-containing
replacement.
Only few new ``opcache.jit_debug`` options that may show the IR.

I understand that working on an RFC for such a complex issue is going to
> take time, but that also gives to opportunity to pair with somebody,
> who, while writing it, will also learn how it works. That would also
> ready improve the debugging/contributing issues.
>

IR documentation could be a good addition and it's going to be created soon
or later.
I don't think it's a blocker, because the IR APIs are quite simple and
intuitive.
Just two public C headers  https://github.com/dstogov/ir/blob/master/ir.h
and https://github.com/dstogov/ir/blob/master/ir_builder.h

Separately, I am not sure why your PR couldn't just replace the JIT that
> we already have? It would IMO not make sense to have two different ones
> at the same time.
>

This is a question.
I decided to keep the old JIT to have an ability to quickly switch back in
case of big problems.
On the other hand we will be able to revert to PHP-8.3.


> Furthermore, I am curious as if you have already done some benchmarks. I
> am curious to learn how well it makes non-benchmark code run faster.
>

This doesn't improve the speed of the real apps yet.
bench.php is 5-10% faster.

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

On Fri, Sep 15, 2023 at 4:03 PM Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:

> If merged to `master`, will that automatically mean that the next
> version of PHP will be PHP 9.0 ?
>
> If so, would that warrant a separate discussion ? (whether there should
> still be a 8.4/8.5/8.6 or not)
>
>
I can't answer this question.
I just came to the state when the new PHP-JIT is good enough to be merged
and we have plenty of time to resolve possible problems until the release.

Thanks. Dmitry.

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

Hi,

After the code-review feedback, one of the most questionable decisions was
changed.
Instead of including IR Framework as a git submodule, now its part is
embedded into php-src.
This will complicate the IR/JIT development a bit, but will simplify things
for everyone else.

I'm going to merge https://github.com/php/php-src/pull/12079 into master
next week.
If someone likes to take a look before, please do it now.

After the merge, I don't plan to do active PHP-JIT development  for 1-2
months (I'll wait for problems, bugs, etc and work on general IR
improvements).
Then, in case of no major problems, I'm going to remove the old JIT
implementation and make a PHP-JIT code-cleanup pass.

Thanks. Dmitry.


On Mon, Sep 11, 2023 at 12:28 PM Dmitry Stogov 
wrote:

> Hi internals,
>
> I'm glad to present a new JIT engine that is going to be used in the next
> major PHP version. Now it's a real optimizing compiler with Intermediate
> Representation similar to Java HotSpot server compiler.
>
> It makes a base for future improvements and eliminates many low-level
> details of the existing PHP JIT. Instead of supporting assembler code for
> different CPUs, now PHP generates a single IR and passes it to a
> PHP-independent JIT engine.
>
> The old JIT implementation is going to be kept for a while.
>
> Everybody are welcome to take a look over tne code
> https://github.com/php/php-src/pull/12079
>
> Thanks. Dmitry.
>

[PHP-DEV] A new JIT engine for PHP-8.4/9

[Dmitry Stogov]

Hi internals,

I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.

It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.

The old JIT implementation is going to be kept for a while.

Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079

Thanks. Dmitry.

Re: [PHP-DEV] ??= and function calls

[Dmitry Stogov]

On Wed, Jul 5, 2023 at 1:15 AM Ilija Tovilo  wrote:

> Hi everyone
>
> I recently discovered some unfortunate behavior of the coalesce
> assignment operator (??=) in combination with function calls. Here's
> the TL;DR:
>
> foo()['bar'] ??= 42;
>
> Currently, this code calls foo() twice. This seems rather unexpected.
> The technical reason as to why this happens is not straight-forward,
> but I will attempt to explain below. The behavior was not specified in
> the RFC (https://wiki.php.net/rfc/null_coalesce_equal_operator) and is
> completely untested, and as such I don't believe it is by design. My
> proposal is to change it so that foo() is only called once.
>
> This is what is happening in detail.
>
> ??= is special in that it needs to evaluate the lhs (left hand side)
> twice. At first, we need to check if the offset exists, then
> conditionally execute the rhs (right hand side), re-fetch the offset
> and assign the rhs value to it. The reason for the re-fetching of the
> offset is that the evaluation of the rhs may invalidate the offset.
> This is explained in the following blog post:
>
> https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-and-memory-safety
> Essentially, the offset may be a pointer into an array element or
> object property. If the rhs frees the array or object, or grows the
> array causing a reallocation (meaning it is moved to some other place
> in memory), the pointer is no longer valid. For this reason, PHP makes
> sure no user code may execute between the fetching of an offset and
> the assignment to it. Normally, that just means evaluating the rhs
> before fetching the offset. In this case, we need to evaluate the lhs
> first to know if we even should evaluate the rhs.
>
> Naively evaluating the lhs again poses a problem for expressions with
> side-effects. For example:
>
> $array[$x++] ??= 42;
>
> We do not want to re-evaluate the entire expression because $x++ will
> lead to a different array offset the second time around. The way this
> is solved is by "memoizing" any compiled expression in the lhs that is
> *not* a variable, meaning not part of the offset that may be
> invalidated. Internally, a variable is considered anything that may be
> written to, i.e. local variables ($foo), properties ($foo->bar,
> Foo::$bar), array offsets ($foo['bar']), and function calls (foo(),
> $foo->bar(), Foo::bar(), $foo(), as they may return a modifiable
> reference). The fact that function calls are included in that list
> leads to the problem presented above. It is not actually necessary to
> exclude them from memoization because their result may not be
> invalidated.
>
> Another inconsistency is that function call arguments will be
> re-evaluated, but only if they are not part of some other expression.
>
> a. foo(bar())['baz'] ??= 42;
> b. foo(bar() + 0)['baz'] ??= 42;
>
> a calls both foo() and bar() twice. b however calls foo() twice but
> bar() only once. That is because the expression bar() + 0 is *not*
> considered a variable and as such gets memoized.
>
>
This is definitely a bug in the original implementation.
In case a function is evaluated twice and returns different values, we
check one value, but assign to another.


> I propose to unconditionally memoize calls (in all forms) when they
> appear in the lhs of a coalesce expression. This will ensure that
> calls are only executed once, including function arguments and the lhs
> of method calls. Consequently, the assignment will be performed on the
> same offset that was previously tested, even if the expression
> contains a function call with side-effects.
>
> The implementation for this change is simple:
> https://github.com/php/php-src/pull/11592
>
> Let me know if you have any concerns. I'm planning on merging this for
> master if there is consensus on the semantics.
>

+1

Thanks. Dmitry.


> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Dmitry Stogov]

On Wed, Mar 1, 2023 at 11:34 AM Niels Dossche 
wrote:

> On 3/1/23 08:42, Dmitry Stogov wrote:
> > On Wed, Mar 1, 2023 at 8:37 AM Max Kellermann  wrote:
> >
> >> On 2023/02/28 23:33, Max Kellermann  wrote:
> >>>> Include cleanups RFC was rejected.
> >>>> No refactoring RFC was presented.
> >>>> A lot of changes that affect all core contributors are committed into
> >>>> master.
> >>>
> >>> Do you mean to imply that code changes that do not implement RFC or
> >>> fix a bug should always be rejected?
> >>
> >> CONTRIBUTING.md says:
> >>
> >>  "PHP welcomes pull requests to add tests, fix bugs and to implement
> >>  RFCs."
> >>
> >> Indeed it appears Dmitry is right - code refactoring is generally NOT
> >> allowed (unless there is an explicit RFC vote, and I havn't seen one).
> >>
> >> This implies that all those commits (and hundreds of others):
> >>
> >>>
> >>
> https://github.com/php/php-src/commit/4177257178d6a1a44f0aa6d6b23d02b91e0a58d3
> >>>
> >>
> https://github.com/php/php-src/commit/9108a32bfe881c3b1e2f3b2949b0e9fe1b9c6dda
> >>>
> >>
> https://github.com/php/php-src/commit/07fe46fb5db9d6f34e72f513ae053fc8c9ad67a
> >>>
> >>
> https://github.com/php/php-src/commit/900472536775b71d5d72a0d66eaa46ae7c7d7ad9
> >>>
> >>
> https://github.com/php/php-src/commit/f0cfebc2b867a6a96a88c4526cf9f3b4cd01f04b
> >>>
> >>
> https://github.com/php/php-src/commit/f079aa2e242b251c6297bddf5365c33c126b7dcc
> >>>
> >>
> https://github.com/php/php-src/commit/b14dd85dca3b67a5462f5ed9b6aa0dc22beb615c
> >>
> >> ... should not have been merged!
> >>
> >
> > At least they should be reviewed once again.
> > I already have questions for the
> >
> https://github.com/php/php-src/commit/9108a32bfe881c3b1e2f3b2949b0e9fe1b9c6dda
> >
>
> Hi Dmitry
>
> I made that commit.
> Please ask me the questions you have and I'll be happy to answer them.
>

See the comment at the commit page on github and let's continue the related
discussion there.
I think github sends notification emails to commit authors.
You probably missed it.

Thanks. Dmitry.


>
> Thanks
> Niels
>
> >
> >> Where do we go from here?  Really revert EVERYTHING?
> >>
> >
> > I'm not too paranoid about small changes and changes in extensions code.
> > I didn't object when you proposed small refactoring steps. (e.g. adding
> > "const" and "static" or small include clenups).
> >
> >
> >> (Reverting just my code refactoring changes but nobody else's would
> >> make no sense at all.  Don't make this personal.)
> >>
> >
> > This is not personal. I saw you are smart and may find and fix not
> trivial
> > bugs. I assume all contributors have good intentions.
> > The problem with your commits, that you started rewriting EVERYTHING (the
> > core parts of php) without a deep knowledge and without agreement with
> > mainteners.
> > They already started to break things (See Nikita's notes about RC
> > debugger).
> > Formally they were committed after a declined RFC.
> >
> > I already proposed a way that might work.
> >
> > Thanks. Dmitry.
> >
> >
> >
> >>
> >> Max
> >>
> >
>
>

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Dmitry Stogov]

On Wed, Mar 1, 2023 at 8:37 AM Max Kellermann  wrote:

> On 2023/02/28 23:33, Max Kellermann  wrote:
> > > Include cleanups RFC was rejected.
> > > No refactoring RFC was presented.
> > > A lot of changes that affect all core contributors are committed into
> > > master.
> >
> > Do you mean to imply that code changes that do not implement RFC or
> > fix a bug should always be rejected?
>
> CONTRIBUTING.md says:
>
>  "PHP welcomes pull requests to add tests, fix bugs and to implement
>  RFCs."
>
> Indeed it appears Dmitry is right - code refactoring is generally NOT
> allowed (unless there is an explicit RFC vote, and I havn't seen one).
>
> This implies that all those commits (and hundreds of others):
>
> >
> https://github.com/php/php-src/commit/4177257178d6a1a44f0aa6d6b23d02b91e0a58d3
> >
> https://github.com/php/php-src/commit/9108a32bfe881c3b1e2f3b2949b0e9fe1b9c6dda
> >
> https://github.com/php/php-src/commit/07fe46fb5db9d6f34e72f513ae053fc8c9ad67a
> >
> https://github.com/php/php-src/commit/900472536775b71d5d72a0d66eaa46ae7c7d7ad9
> >
> https://github.com/php/php-src/commit/f0cfebc2b867a6a96a88c4526cf9f3b4cd01f04b
> >
> https://github.com/php/php-src/commit/f079aa2e242b251c6297bddf5365c33c126b7dcc
> >
> https://github.com/php/php-src/commit/b14dd85dca3b67a5462f5ed9b6aa0dc22beb615c
>
> ... should not have been merged!
>

At least they should be reviewed once again.
I already have questions for the
https://github.com/php/php-src/commit/9108a32bfe881c3b1e2f3b2949b0e9fe1b9c6dda


> Where do we go from here?  Really revert EVERYTHING?
>

I'm not too paranoid about small changes and changes in extensions code.
I didn't object when you proposed small refactoring steps. (e.g. adding
"const" and "static" or small include clenups).


> (Reverting just my code refactoring changes but nobody else's would
> make no sense at all.  Don't make this personal.)
>

This is not personal. I saw you are smart and may find and fix not trivial
bugs. I assume all contributors have good intentions.
The problem with your commits, that you started rewriting EVERYTHING (the
core parts of php) without a deep knowledge and without agreement with
mainteners.
They already started to break things (See Nikita's notes about RC
debugger).
Formally they were committed after a declined RFC.

I already proposed a way that might work.

Thanks. Dmitry.



>
> Max
>

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Dmitry Stogov]

On Wed, Mar 1, 2023 at 1:21 AM Max Kellermann  wrote:

> On 2023/02/28 22:31, Dmitry Stogov  wrote:
> >
> https://github.com/php/php-src/commit/0270a1e54c0285fa3c89ee2b0120073ef57ab5fa
>
> This kind of change was favored by a supermajority.
>
> You argue that this supermajority vote is irrelevant, and formally it
> indeed is, but pondering about formalities is kind of ignorant against
> the now well-known community opinion.
>
> >
> https://github.com/php/php-src/commit/b98f18e7c3838cf587a1b6d0f033b89e9909c79d
>
> No vote was made on this, therefore this doesn't violate any community
> rules, does it?
>

Please reread https://wiki.php.net/RFC/voting#voting
RFC is accepted by a supermajority of the primary vote.
The secondary votes may be used to make decisions about implementation
details.

Thanks. Dmitry.


>
> If you think this should be reverted, explain why.
>
> >
> https://github.com/php/php-src/commit/42577c6b6b7577c57c161ee4a74cb193382bf1e0
>
> Favored by supermajority, see above.
>
> >
> https://github.com/php/php-src/commit/c7637ed1c03f556c6fb65884cfc5bfea4920b1c7
>
> No vote, no rule violation, see above.
>
> >
> https://github.com/php/php-src/commit/371ae12d890f1887f79b7e2a32f808b4595e5f60
>
> As you see in the commit message, this implements an (unwritten) rule
> cited by Nikita Popov (which is now written as of
> https://github.com/php/php-src/pull/10630).  I personally don't agree
> with this rule (there's a thread on this mailing list about it), and I
> would favor reverting this commit - I only submitted this trying to
> help with implementing a rule even though I don't agree with it.
>
> If this gets reverted, then https://github.com/php/php-src/pull/10630
> should be reverted as well.  Again, not my opinion, I'm just trying to
> help implement somebody else's opinion.
>
> Max
>

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Dmitry Stogov]

On Wed, Mar 1, 2023 at 12:04 AM Max Kellermann  wrote:

> On 2023/02/28 21:16, Dmitry Stogov  wrote:
> > Recently we voted for inluce cleanup RFC
> > https://wiki.php.net/rfc/include_cleanup and it was declined.
> > Despite that a series of code refactoring commits from Max were silently
> > merged into the master.
> > As this is a violation of the community rules and we should do something.
>
> I don't get any of that.  Please be more specific.
>
> Which community rule was violated by whom?
>

Merging the things that were rejected. You may name this differently but
this is still code refactoring.

In your opinion, what exactly does the outcome of the vote mean?  Does
> it mean that include cleanups are now forbidden (despite being wanted
> by the majority of voters)?  Or does it mean that nothing changes
> because no new rule has taken effect?  (I asked that already, but
> nobody replied.)
>

Include cleanups RFC was rejected.
No refactoring RFC was presented.
A lot of changes that affect all core contributors are committed into
master.

If you think this is questionable, we may ask for help from some arbitr.


>
> What do you mean by "merged silently"?  All of my PRs were submitted
> in the public, and everybody had a chance to comment on these (which
> you did, for example, in https://github.com/php/php-src/pull/10641).
> It usually takes a week or so before they are merged.  If you feel
> that is not enough time, why not post a RFC and vote on a mandatory
> minimum review duration for all merges/pushes?
>

I don't review every PR. Only when I asked. I'm mainly busy with new
development and bug fixes.


> Though, by contrast, you merge most of your own PRs shortly after you
> create them without any code review.  Quite often, you even push
> commits without any PR.  In my opinion, that's more "silent" than my
> work, don't you agree?
>

Currently, I merge into master only bug fixes.
And yes, sometimes my fixes may introduce new bugs.
My new development is done in a separate branch and will be presented in
RFC when ready.


> Which specific commits do you wish to revert?  Is this about include
> cleanups (none of which were merged) or about header splitting (which
> a supermajority voted for) or about other kinds of code refactoring
> (which was not voted on)?
>

All code refactoring commits.
Can you imagine you commited something like this into Linux, JVM, GCC?


> > Then most of the work should be done in a separate branch and merged
> > into the master all together after a final review.
>
> The problem with merge conflicts was your major complaint about branch
> merging (and that was only about merging bug fixes, not about merging
> two volatile branches together) - and now you suggest something that
> will certainly lead to merge conflicts because your suggestion
> postpones the big merge for as long as possible.  That will inflict
> major pain to PHP maintainers (though not to outside contributors like
> me, so why would I care).
>

PHP-6 was developed in a separate branch and we were able to stop it when
understood that it is not good enough.
PHPNG was developed in a separate branch and was presented and accepted
only when we showed the benefits.
A new JIT has been developed in a separate branch for more than a year...


> Another big problem: if it's uncertain that some changes ever get
> merged, because the "final review" may reject it after months or years
> of work, nobody will ever want to clean up the PHP code again, because
> it's very likely that you'll veto it again, and then all the time
> would be wasted.  Not a great prospect.  If you want to scare away
> contributors, that's how to do it.
>

As I said, I won't object to the terms of accepted RFC.
I already made much more noise than I liked.

My opinion is: if a patch improves a piece of code, it should be
> merged.  Of course, whether something is an improvement is debatable;
> but postponing that decision is pointless and harmful.
>

Changing code back and force without a plan is also harmful.
I proposed to you a way to do what you like in agreement with other
contributors.
Doing this without agreement won't work.

Thanks. Dmitry.


> Max
>

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Dmitry Stogov]

On Tue, Feb 28, 2023 at 11:59 PM Dan Liebner  wrote:

> Which commit?
>

just some of them:
https://github.com/php/php-src/commit/0270a1e54c0285fa3c89ee2b0120073ef57ab5fa
https://github.com/php/php-src/commit/b98f18e7c3838cf587a1b6d0f033b89e9909c79d
https://github.com/php/php-src/commit/42577c6b6b7577c57c161ee4a74cb193382bf1e0
https://github.com/php/php-src/commit/c7637ed1c03f556c6fb65884cfc5bfea4920b1c7
https://github.com/php/php-src/commit/371ae12d890f1887f79b7e2a32f808b4595e5f60

Thanks. Dmitry.


>
> On Tue, Feb 28, 2023, 3:17 PM Dmitry Stogov 
> wrote:
>
>> Hi @internals,
>>
>> I have to say that we came to a serious conflict.
>>
>> Recently we voted for inluce cleanup RFC
>> https://wiki.php.net/rfc/include_cleanup and it was declined.
>> Despite that a series of code refactoring commits from Max were silently
>> merged into the master.
>> As this is a violation of the community rules and we should do something.
>> In my opinion, this should be reverted (I would even think about rebasing
>> to not pollute the git history).
>>
>> Personally, I don't like this refactoring, because it is mainly about
>> coding preferences and habits.
>> Anyway, I see that some people like this. Maybe this may attract new
>> developers.
>>
>> OK. Let's do this, but do this in a managed way. The massive uncontrolled
>> changes is the main problem in the current situation.
>> Let's define the goal(s), rules, make a plan, summarize this in a new RFC,
>> accept it.
>> Then most of the work should be done in a separate branch and merged into
>> the master all together after a final review.
>> I (and other authority contributors) wouldn't be able to object against
>> the
>> terms accepted in RFC.
>> So a good RFC should be a half of success...
>> It would be great if PHP Foundation could assign some experienced
>> developer(s) to be part of this work.
>>
>> Thanks. Dmitry.
>>
>

[PHP-DEV] PHP code refactoring (was: include cleanup)

[Dmitry Stogov]

Hi @internals,

I have to say that we came to a serious conflict.

Recently we voted for inluce cleanup RFC
https://wiki.php.net/rfc/include_cleanup and it was declined.
Despite that a series of code refactoring commits from Max were silently
merged into the master.
As this is a violation of the community rules and we should do something.
In my opinion, this should be reverted (I would even think about rebasing
to not pollute the git history).

Personally, I don't like this refactoring, because it is mainly about
coding preferences and habits.
Anyway, I see that some people like this. Maybe this may attract new
developers.

OK. Let's do this, but do this in a managed way. The massive uncontrolled
changes is the main problem in the current situation.
Let's define the goal(s), rules, make a plan, summarize this in a new RFC,
accept it.
Then most of the work should be done in a separate branch and merged into
the master all together after a final review.
I (and other authority contributors) wouldn't be able to object against the
terms accepted in RFC.
So a good RFC should be a half of success...
It would be great if PHP Foundation could assign some experienced
developer(s) to be part of this work.

Thanks. Dmitry.

Re: [PHP-DEV] [VOTE] include cleanup

[Dmitry Stogov]

On Mon, Feb 13, 2023 at 12:51 PM Max Kellermann  wrote:

> On 2023/02/13 10:28, Dmitry Stogov  wrote:
> > It's OK when commits are reverted.
> > You are working in a common repository, and if your commits become
> stoppers
> > for others they have to be reverted.
> > Some of my commits were reverted as well.
>
> That doesn't explain why you demanded to revert everything instead of
> applying my trivial single-line fix.
>
> > Having too many dependent commits and inability to revert a single one
> > became an additional trouble and drew more attention to things you are
> > doing...
> > I didn't care about a single header change, but I do care about 100
> > dependent commits.
>
> I don't get it, what's your point here?
>
> The fact that these dependencies exist is a result of the unclean
> state of the PHP code base, something my work aims to improve.  The
> number of dependencies after my PRs was lower than before, and that's
> good.
>
> The "inability to revert a single one" is not a problem that needed to
> be solved, because a revert was never necessary - there was a trivial
> fix (that did work, contrary to your assertion).
>
> > After all, this includes cleanup is really questionable, and the current
> > vote result shows that is not my sole opinion.
> > Personally, I think this work might be very welcome during PHP-7.0
> > development together with other re-factoring(s).
> > Massive permutation changes in a minor release are not acceptable for me.
> > Maybe it makes sense to target them to PHP-9.0
>
> The vote is not about WHEN this cleanup can be done - it's about
> WHETHER at all.
>
> Voting "yes" does not imply that this must be done for 8.3.  The RFC
> suggests that it could be 8.3 or 9.0, but that decision is not part of
> the vote.
>
> Voting "no" means you never want this cleanup to happen, ever, not for
> 8.3 and not for 9.0.
>
> So if you're not really opposed to such a kind of cleanup in general,
> don't vote "no".
>

The RFC proposes merging into the "master" branch.
And I voted exactly against this.

Thanks. Dmitry.

Re: [PHP-DEV] [VOTE] include cleanup

[Dmitry Stogov]

On Mon, Feb 13, 2023 at 11:35 AM Max Kellermann  wrote:

> On 2023/02/13 01:58, "G. P. B."  wrote:
> > We have had completely broken builds for longer days due to some other
> > random changes, and we didn't revert them but fixed them as a follow-up.
> > We still, for over 6 months now, have a "broken" ASAN build due to phpdbg
> > messing up the analyser and crashing the test runner on 8.2 and master,
> > something that multiple core devs, me included, need to work around by
> > monkey patching the run-test.php file.
>
> I had a feeling there are double standards at play.  The way my work
> was dealt with is unprecedented!
>
> In the git history, I could not find any other set of PRs that was
> reverted completely just for a minor one-line issue.
>
>
> Stuff breaks all the time, and every breakage is, of course, a mistake
> that should have been handled with more care, and something to learn
> from.  Sometimes, a revert is the right solution, but in my case, the
> (demand of a) revert was unreasonable and hasty.
>
>
> > As a final note, if the complaint had been made by anyone else other than
> > Dmitry, I doubt these changes would have been reverted, and can we please
> > stop pretending otherwise.
>
> I forget one include, break an exotic build in master branch, Dmitry
> demands complete revert of 4 PRs / 61 commits (60 of which are
> unrelated to the breakage).
>
> Dmitry breaks the whole build for everybody (including the CI) and
> introduces a crash bug, merged through all three branches
> (https://github.com/php/php-src/commit/a21195650e53), no revert.
>
> (Don't misunderstand, everybody makes mistakes, I just point out the
> obvious double standard.)
>
> Then everybody is raving about my include comments and forward
> declarations, yet the PHP code base has many of these.  Turns out
> those who complained the loudest have authored some of these in the
> past.
>
> Max
>

Max,

It's OK when commits are reverted.
You are working in a common repository, and if your commits become stoppers
for others they have to be reverted.
Some of my commits were reverted as well.

Having too many dependent commits and inability to revert a single one
became an additional trouble and drew more attention to things you are
doing...
I didn't care about a single header change, but I do care about 100
dependent commits.

After all, this includes cleanup is really questionable, and the current
vote result shows that is not my sole opinion.
Personally, I think this work might be very welcome during PHP-7.0
development together with other re-factoring(s).
Massive permutation changes in a minor release are not acceptable for me.
Maybe it makes sense to target them to PHP-9.0

Thanks. Dmitry.

Re: [PHP-DEV] RFC: rules for #include directives

[Dmitry Stogov]

Here are my comments about the last PR
https://github.com/php/php-src/pull/10345
Max asked to repost them in this thread:

In my opinion this should not be accepted.

Despite the intention is good, this huge patch doesn't improve anything but
adds new questions.

   - It introduces new include files (e.g. zend_char.h, what was wrong with
   zend_portability.h?)
   - It adds a lot of forward declarations (e.g. typedef struct _
   )
   - It adds almost useless comments that are not goigg to be kept as to
   date (e.g. #include "zend_portability.h" // for BEGIN_EXTERN_C,
   zend_portability.h defines all base macros for Zend engine)
   - zend.c adds a number of commented includes (is this some kind of TODO?)
   - > is included in many other *.h files instead of single
   zend_portability.h or zend_types.h.

I see all these changes as a source permutation that don't add significant
value. On the other hand:

   - this may introduce PHP build failures on some untested configurations
   (like it was with DTRACE)
   - we have to support several PHP branches at once and merging fixes
   between very different branches is going to introduce problems
   - this changes may break compilation of third-party software (e.g.
   xdebug). Not a huge problem, but it's not great to do this in a minor
   version update.




On Mon, Jan 16, 2023 at 8:22 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> As commented yesterday on one of the PRs, I strongly agree with the
> cleanups. Our code has implicit dependencies and if you reorder the
> includes in the same file, you can break builds. That shouldn't ever
> happen.
>
> I also agree that dtrace breaking is a failure of CI and testing, not
> necessarily the patch (I haven't reviewed that PR carefully, maybe
> there was some carelessness but if it's not tested, it's hard to blame
> anyone).
>
> Lastly, I do not care for the comments which explain why a header is
> included. My experience is that these comments bitrot quite quickly.
>
> Overall, I hope we can resume this effort.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: rules for #include directives

[Dmitry Stogov]

Hi Max,

Thanks for describing the situation.

We do not often vote on implementation changes that don't affect PHP
language itself.
At first, I even considered these changes as "I don't care".
However, they are turned up into huge patches that make troubles for PHP
maintenance.
As we didn't come to an agreement, the best decision should be done by the
PHP community.

In the current state of the implementation I'm personally against this, but
I might change my opinion if this is targeted to PHP-9 and the
implementation is done in a some better way.

Thanks. Dmitry.


On Mon, Jan 16, 2023 at 3:03 PM Max Kellermann  wrote:

> Hi,
>
> in the past weeks, I submitted four PRs for cleaning up the #includes
> in the PHP code base:
>
>  https://github.com/php/php-src/pull/10216
>  https://github.com/php/php-src/pull/10220
>  https://github.com/php/php-src/pull/10279
>  https://github.com/php/php-src/pull/10300
>
> I saw that the existing #include directives were inconsistent,
> incomplete and bloated; things just worked by chance, not by design,
> because there were a few headers which just included everything.  I
> wanted to help clean up this mess that had accumulated over two
> decades.
>
> All PRs were welcomed by different reviewers and were merged; there
> was just one minor criticism by Dmitry Stogov who thought the code
> comments explaining many non-obvious #includes should be removed:
>
> https://github.com/php/php-src/pull/10216#issuecomment-1375140255
>
> > I don't think we should include the comments like // for
> > BEGIN_EXTERN_C (and similar). The are good for review only.  I'm
> > indifferent to these changes and don't object.
>
> Yesterday, when a DTrace-specific regression was reported
> (https://github.com/php/php-src/pull/10220#issuecomment-1383035139),
> after which Dmitry asked to revert the whole PR:
>
>  https://github.com/php/php-src/pull/10220#issuecomment-1383658247
>
> Instead, I submitted a trivial fix for the regression
> (https://github.com/php/php-src/pull/10334), which was rejected by
> Dmitry
> (https://github.com/php/php-src/pull/10220#issuecomment-1383706602)
> but confirmed by the original reporter
> (https://github.com/php/php-src/pull/10220#issuecomment-1383802334).
>
> In spite of that, Dmitry demanded to revert all of my #include
> cleanups
> (https://github.com/php/php-src/pull/10220#issuecomment-1383739816):
>
> > I'm asking to revert all these include cleanup commits!  This is
> > just a useless permutation. e.g. 68ada76 adds typedef struct _* that
> > we didn't need before. How is this clearly?
>
> ... which so far only Derick Rethans agreed to:
>
> https://github.com/php/php-src/pull/10220#issuecomment-1383784480
>
> > FWIW, I agree with Dmitry here, and these should all be reverted. It
> > adds nothing but clutter.
>
> Christoph M. Becker performed the revert and suggested doing an RFC
> (https://github.com/php/php-src/pull/10220#issuecomment-1383789100)
> and vote on it.
>
> So this is a first draft of my proposal which I'd like to discuss with
> you:
>
>  https://github.com/php/php-src/pull/10338
>
> Max
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Reason for ZEND_JIT_COUNTER_INIT set to 32531?

[Dmitry Stogov]

Oh, probably this is just the biggest prime number that fits into a signed
16-bit number :)

On Mon, Jan 17, 2022 at 10:49 AM Su, Tao  wrote:

> Thanks Dmitry for the information.
>
> With a few debug sessions, I found that 32531 is working well
> for any thresholds, and is also a big prime number :-).
>
>
> -Original Message-
> From: Dmitry Stogov 
> Sent: Monday, January 17, 2022 1:37 PM
> To: Su, Tao 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] Reason for ZEND_JIT_COUNTER_INIT set to 32531?
>
> This it's my choice.
> This number is common for all JIT counters (hot_loop, hot_func,
> hot_return).
> It's value was selected to provide the best precision when different
> counters have different thresholds.
> Unfortunately, I can't remember the exact equations or logic I used at
> that time.
>
> Thanks. Dmitry.
>
> On Thu, Jan 13, 2022 at 1:01 PM Su, Tao  wrote:
>
> > Hi Internal,
> > I am not sure this is a correct mail list for asking source code
> > related question.
> > If not, I am sorry. Appreciate you guys' help.
> >
> > I am reading PHP8 JIT related source code and found that zend_jit.h
> > has a magic definition ZEND_JIT_COUNTER_INIT as 32531 which I do not
> > quite understand how this number was chosen and why?
> > Anybody can provide some historic information?
> > #define ZEND_JIT_COUNTER_INIT 32531
> >
> > A code example using this definition (looks like the 2nd parameter
> > computes into a fixed number if hot_func is set by php.ini)
> > ZEND_OPCODE_TAIL_CALL_EX(zend_jit_trace_counter_helper,
> > ((ZEND_JIT_COUNTER_INIT + JIT_G(hot_func) - 1) /
> > JIT_G(hot_func)));
> >
> >
> > ===
> > Tony Su (Su, Tao)
> > make a 'lazy' programmer diligently with efficiency
> >
> >
>

Re: [PHP-DEV] Reason for ZEND_JIT_COUNTER_INIT set to 32531?

[Dmitry Stogov]

This it's my choice.
This number is common for all JIT counters (hot_loop, hot_func, hot_return).
It's value was selected to provide the best precision when different
counters have different thresholds.
Unfortunately, I can't remember the exact equations or logic I used at that
time.

Thanks. Dmitry.

On Thu, Jan 13, 2022 at 1:01 PM Su, Tao  wrote:

> Hi Internal,
> I am not sure this is a correct mail list for asking source code related
> question.
> If not, I am sorry. Appreciate you guys' help.
>
> I am reading PHP8 JIT related source code and found that zend_jit.h has a
> magic definition
> ZEND_JIT_COUNTER_INIT as 32531 which I do not quite understand how this
> number was chosen and why?
> Anybody can provide some historic information?
> #define ZEND_JIT_COUNTER_INIT 32531
>
> A code example using this definition (looks like the 2nd parameter
> computes into a fixed number if hot_func is set by php.ini)
> ZEND_OPCODE_TAIL_CALL_EX(zend_jit_trace_counter_helper,
> ((ZEND_JIT_COUNTER_INIT + JIT_G(hot_func) - 1) /
> JIT_G(hot_func)));
>
>
> ===
> Tony Su (Su, Tao)
> make a 'lazy' programmer diligently with efficiency
>
>

Re: [PHP-DEV] VM kinds

[Dmitry Stogov]

I prefer to keep GOTO and SWITCH VMs. It's easy to drop something, but it's
going to be much more complex to reimplement it again.

Note that HYBRID VM (based on CALL and GOTO VMs) was introduced only in
PHP-7.2, because GOTO was already implemented a long time ago. In the
future, it's possible to extend HYBRID VM, to make it work with
GCC-incompatible compilers through SWITCH. We might also like to move from
direct-threaded to indirect-threaded dispatch.

Thanks. Dmitry.

On Wed, Nov 10, 2021 at 11:35 AM Nikita Popov  wrote:

> On Wed, Nov 10, 2021 at 8:13 AM Tim Starling 
> wrote:
>
> > What are VM kinds for? Are they just a prototyping tool to allow
> > different implementation strategies to be benchmarked? Or are they
> > permanent? Does anyone use them?
> >
> > I ask because I'm working on a VM bug, and non-default VM kinds make
> > already complex code even more complex and harder to edit.
> >
> > -- Tim Starling
> >
>
> I don't think anyone uses them, and the GOTO/SWITCH VMs receive little
> testing in practice (we don't use them in CI), and I believe they're not
> supported by the JIT either. Personally, I would be fine with simply
> dropping them, as they do add additional maintenance burden without any
> apparent benefit. Maybe Dmitry has some thoughts on this.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] timelib performance fix

[Dmitry Stogov]

On Tue, Aug 31, 2021 at 11:58 PM Ben Ramsey  wrote:

>
> Is it solely a bug fix and/or performance improvement?
>

This is not a bug fix, this is a fix for a performance problem.

Thanks. Dmitry.

[PHP-DEV] timelib performance fix

[Dmitry Stogov]

Hi Derick,

Please, let me know you decision according
https://github.com/derickr/timelib/pull/99

This workaround fix makes ~170 times improvement on "new DateTimeZone()"
and as result visible improvement on some real-life apps (e.g Symfony demo
gets ~7% according to callgrind).
This is a huge difference.

The fix was proposed more than a half year ago...
It would be great to include it into PHP-8.1 release.

Thanks. Dmitry.

[PHP-DEV] FFI Type Reflection API

[Dmitry Stogov]

Hi,

Last week, at a PHP conference, we discussed some missing parts of ext/ffi
with one of the most extrimal FFI user - Alexandr Lisachenko. One of the
things he is missing is a FFI Type Reflection API. Actually, this is a
simple and self-contained feature, that implementation took me a couple of
hours.

https://github.com/php/php-src/pull/7217

This doesn't touch any existing code in ext/ffi, just add the API that is
better visible through stub:
https://github.com/php/php-src/pull/7217/files#diff-3651c407d02a2a152d9aba6e484f6ae7f4c2c85fa2992274d76c0e18364c7e6fL75-R96

Unfortunately, PHP-8.1 is closed for new RFC, so we can merge this as a
self-contained feature, or wait for the next version. I ask to merge this
into PHP-8.1, but won't do this, in case of any objections.

Thanks. Dmitry.

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

[Dmitry Stogov]

Return void by reference should be disabled (not deprecated)

On Wed, Jun 30, 2021 at 12:32 PM Nikita Popov  wrote:

> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The
> vote closes on 2021-07-14.
>
> This RFC is a collection of various deprecation suggestions from different
> people. Each deprecation is voted separately, and should be considered on
> its own merit.
>
> Most deprecations should be uncontroversial, but there are some more
> contentious ones as well: See https://externals.io/message/113657 for
> additional discussion.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [VOTE] Deprecate autovivification on false

[Dmitry Stogov]

Hi Kamil,

PHP warnings are tricky, error handlers may cause side effects, throw
exceptions, etc.
Especially, for this deprecation you'll have to handle a new "slow" path
(in VM and JIT) that should return back to the main path.

Thanks. Dmitry.



On Fri, Jun 11, 2021 at 3:13 PM Kamil Tekiela  wrote:

> Hi Dmitry,
>
> Thanks for voicing your concerns.
> I have started writing implementation and it is definitely challenging for
> me, because I am not that experienced with PHP internals yet.
> https://github.com/php/php-src/pull/7131
>
> Almost every implementation requires some amount of work. I would like to
> ask you for more details on why you think this particular change is
> infeasible. Do you see any problems that the implementation of this
> deprecation message would cause? Would it be better to wait for PHP 9.0 and
> remove it without deprecation?
> As I see it, we already have an error for other scalar types. For false,
> we will just need to throw a deprecation notice in the same places. It
> doesn't require a major rewrite of PHP engine from what I can tell.
>
> Regards,
> Kamil
>

Re: [PHP-DEV] [VOTE] Deprecate autovivification on false

[Dmitry Stogov]

On Fri, Jun 11, 2021 at 12:19 PM Claude Pache 
wrote:

>
> >
> > I wouldn't care about disabling autovivification on false, but I vote
> "No",
> > because I'm against the deprecation.
>
>
> Do you mean, you wouldn’t care if it went directly from “working without
> notice” in PHP 8.0 to “fatal error” in PHP 8.1? That would be extremely
> hostile for large code bases in their upgrading process, as it is in
> general not a feature that can be checked and corrected statically.
>

The RFC doesn't provide implementation, and I see that the implementation
of this deprecation may be not as simple as expected.

Thanks. Dmitry.


> —Claude

Re: [PHP-DEV] [VOTE] Deprecate autovivification on false

[Dmitry Stogov]

hi,

I wouldn't care about disabling autovivification on false, but I vote "No",
because I'm against the deprecation.

Thanks. Dmitry.

On Wed, Jun 9, 2021 at 11:24 PM Kamil Tekiela  wrote:

> Hi Internals,
>
> I have limited the RFC to disabling autovivification on false only, which
> was the initial scope of the RFC. The only two possible cases remaining
> will be undefined and null. After what Tyson Andre clearly explained, null
> is commonly used and leads to many more complex situations.
>
> I have opened voting on https://wiki.php.net/rfc/autovivification_false
> which will end on 2021-06-23T20:00:00Z
>
> Link to the discussion thread: https://externals.io/message/114595
>
> The implementation is pending, but if someone wants to suggest one, please
> feel free.
>
> Regards,
> Kamil
>

[PHP-DEV] Re: timelib inefficiency

[Dmitry Stogov]

Hi Derick,

I saw you have landed the recent updates of timelib to PHP master.
There are few ongoing improvements:

https://github.com/derickr/timelib/pull/103 - an obvious code motion, that
avoid useless "year" calculation

https://github.com/derickr/timelib/pull/104 - an adoption of my old idea,
that prevents unnecessary 64-bit divisions, to new code-base

https://github.com/derickr/timelib/pull/99 - this is the old and the most
important one. It makes **170 times** speed-up on each very usual
timelib_parse_zone() call. The real problem is in timelib_lookup_abbr().
Actually the algorithm of timelib_lookup_abbr() is highly inefficient and
most probably improper, but this simple check just eliminates the need for
the call to timelib_lookup_abbr() for many usual cases. Just this patch
makes more than 3% improvement on the Symfony Demo app (that is not just a
"hello world").

I hope the landing of these improvements won't take another month.

Thanks. Dmitry,

On Thu, Mar 4, 2021 at 4:13 PM Dmitry Stogov  wrote:

> hi,
>
> On Thu, Mar 4, 2021 at 3:30 PM Derick Rethans  wrote:
>
>> Hi,
>>
>> I saw the PRs coming in, I'll reply inline:
>>
>> On Thu, 4 Mar 2021, Dmitry Stogov wrote:
>>
>> >
>> https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58
>>
>> As Nikita already commented, this now seems to introduce flakeyness into
>> tests.
>>
>> > And created 3 pull request for timelib:
>> >
>> > https://github.com/derickr/timelib/pull/98
>>
>> That looks reasonable. I'm currently working on implementing
>> https://github.com/derickr/timelib/issues/14 which will also touch that
>> code, so I'll look at it as part of that work.
>>
>> > https://github.com/derickr/timelib/pull/99
>>
>> Is incorrect, the tzfile 5 man page says:
>>
>> Time zone designations should consist of at least three (3) and
>> no more
>> than six (6) ASCII characters from the set of alphanumerics
>>
>
> timelib (timezonedb.h and fallbackmap.h) doesn't have abbreviation longer
> than 5 characters, but has single char abbreviations.
>
>
>>
>> I am curious to as to why this routine was called so often though, as
>> looking for abbreviations isn't something that should have be be done
>> often.
>>
>
> Every time you parse a time zone name (including a date with timezone) you
> always (except for UTS and GMT) perform a linear search through all entries
> listed in timezonedb.h (1128 string comparisons + 1128*2 lowercasing +
> 1128*2 calls to strlen()), and only then take a look for timezone name,
> that may be already cached.
>
>
>>
>> > https://github.com/derickr/timelib/pull/100
>>
>> This new routine is perhaps faster, but it is also extremely more
>> complex, with little comments. It's unlikely I would want to incorporate
>> it in its current form.
>>
>
> What comments do you like?
> We first guess the year dividing days to 365, then check if our guess is
> right (number of days from the start of the guessed year fits into this
> year), and then continue searching.
> This is like a binary search, but with base 365 and the rule to check the
> leap year.
>
>
>> > Please, verify and merge the timelib patches into PHP.
>> > Please, let me know if this will take time.
>>
>> It will certainly take time :-)
>>
>> > I fixed only the visible, most significant and obvious bottlenecks.
>> > It's possible to improve timelib more...
>>
>> I'm sure it is! The code is 17 years old by now!
>>
>
> yeah, this is the problem. Nobody likes to improve it. I'm interested only
> because it significantly affects PHP performance.
>
> Thanks. Dmitry.
>
>
>>
>> cheers,
>> Derick
>>
>

Re: [PHP-DEV] RFC: PHP JIT/arm64 port

[Dmitry Stogov]

Yeah, I suppose this is going to be a big task and we will have to
collaborate a lot.
anyway, next week... It's already Friday evening.

Thanks. Dmitry.


On Fri, Mar 19, 2021 at 5:20 PM Hao Sun  wrote:

> Hi Dmitry,
>
> Thanks for your reply.
>
>
>
> Yes. Sure. I will CC you next time.
>
>
>
> As I mentioned in the previous email, this is our (ARM) initial effort to
> enable JIT/arm64 port and there might exist some potential bugs in
> implementation or something we haven’t considered/designed soundly.
>
> Please let us know if you have any question.
>
>
>
> Thanks,
>
> Hao
>
>
>
>
>
> *From:* Dmitry Stogov 
> *Sent:* Friday, March 19, 2021 9:35 PM
> *To:* Hao Sun 
> *Cc:* internals@lists.php.net; nd 
> *Subject:* Re: [PHP-DEV] RFC: PHP JIT/arm64 port
>
>
>
> Hi Hao,
>
>
>
> I'm the author of JIT for PHP. Please CC me next time, I read @internals
> only from time to time...
>
> I'll try to take a look into your implementation next week.
>
> I'm not sure how much time I'll be able to invest yet, I'll have to
> discuss this with my management.
>
>
>
> Thanks. Dmitry.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 17, 2021 at 6:28 AM Hao Sun  wrote:
>
> Hi Internals,
>
> Currently PHP JIT only supports x86 and x86_64 CPUs on POSIX platforms and
> Windows.[1] With the prevalence of PHP language and the notable
> growth of ARM-based servers market, we believe JIT/arm64 would be in
> urgent need in the near future.
>
> As an initial effort to enable PHP JIT/arm64, we (ARM) have supported the
> basic functionality, and (partially) implemented the compilation for
> several opcodes. Currently a number of simple JIT test cases from PHP test
> framework can be passed on ARM-based machine. There are still a lot
> of missing parts, such as hot loops, class/object/array operations,
> exception handling, etc, and we will continue working on them.
>
> We would like to share our work with you (See the draft patch
> https://github.com/shqking/php-src/commit/6aaf935).
> Any feedback would be greatly appreciated, and please let we know if
> anyone wants to contribute to this port.
>
> Thanks,
> Hao SUN
> Email: hao@arm.com<mailto:hao@arm.com>
>
> ---
> Main updates:
> 1. JIT backend for AArch64
> A new alternative, i.e. AArch64, was added while building PHP JIT. See the
> updates in the following files. Note that we adopt capstone[2] for
> disassembly on AArch64.
>
>   build/Makefile.global
>   ext/opcache/config.m4
>   ext/opcache/config.w32
>   ext/opcache/jit/Makefile.frag
>   ext/opcache/jit/zend_jit.c
>   ext/opcache/jit/zend_jit_vm_helpers.c
>   ext/opcache/jit/zend_jit_disasm_arm64.c
>   ext/opcache/jit/zend_jit_gdb.c
>   ext/opcache/jit/zend_jit_perf_dump.c
>
> 2. DynASM library
> PHP JIT uses DynASM[3] (developed for LuaJIT project) to generate native
> code on the fly. We added two useful but missing features, global label
> reference and dynamic register names, into DynASM/arm64. See the updates
> in files:
>
>   ext/opcache/jit/dynasm/dasm_arm64.h
>   ext/opcache/jit/dynasm/dasm_arm64.lua
>
> Note that these two features are available on DynASM/x86.
>
> 3. compilation for opcodes on AArch64
> Our main work falls in the following files.
>
>   ext/opcache/jit/zend_jit_arm64.h
>   ext/opcache/jit/zend_jit_arm64.dasc
>   ext/opcache/jit/zend_jit_internal.h
>   Zend/zend_vm_opcodes.h
>
> * AArch64 registers and calling conventions are defined.
>
> * Instruction cache must be flushed for the JIT-ed code on AArch64. See
> macro JIT_CACHE_FLUSH in file 'zend_jit_internal.h'.
>
> * We have (partially) implemented the compilation for several opcodes,
> mainly for the function-based JIT (with opcache.jit=1203). Currently,
> test cases involving internal function call (e.g. var_dump), additions
> with integers/floating-point numbers, integer overflows and simple
> exception, can be supported now. See our newly added test cases under
> directory 'ext/opcache/tests/jit/arm64/'.
>
> * Trace counter stubs are implemented for tracing JIT (with
> opcache.jit=1255). See zend_jit_hybrid_trace_counter_stub() and
> zend_jit_hybrid_hot_trace_stub() in file 'zend_jit_arm64.dasc'. Hot
> functions can be recognized and compiled successfully. See the test case
> 'hot_func_002.phpt'.
>
> How to build and test:
> Our local test environment is an ARM-based server with Ubuntu 20.04 and
> GCC-10. We follow the building commands as shown in the readme file [4].
> Note that library capstone should be installed in advance.
>
> We suggest running the JIT test cases using the following command. In our
> local test, 59 out of all 128 cases can be passed currently.
>   $ make test TESTS='-d opcache.jit=1203 ext/opcache/tests/jit/'
>
> [1] https://wiki.php.net/rfc/jit
> [2] https://www.capstone-engine.org/
> [3] https://luajit.org/dynasm.html
> [4] https://github.com/php/php-src
>
>

Re: [PHP-DEV] RFC: PHP JIT/arm64 port

[Dmitry Stogov]

Hi Hao,

I'm the author of JIT for PHP. Please CC me next time, I read @internals
only from time to time...
I'll try to take a look into your implementation next week.
I'm not sure how much time I'll be able to invest yet, I'll have to discuss
this with my management.

Thanks. Dmitry.





On Wed, Mar 17, 2021 at 6:28 AM Hao Sun  wrote:

> Hi Internals,
>
> Currently PHP JIT only supports x86 and x86_64 CPUs on POSIX platforms and
> Windows.[1] With the prevalence of PHP language and the notable
> growth of ARM-based servers market, we believe JIT/arm64 would be in
> urgent need in the near future.
>
> As an initial effort to enable PHP JIT/arm64, we (ARM) have supported the
> basic functionality, and (partially) implemented the compilation for
> several opcodes. Currently a number of simple JIT test cases from PHP test
> framework can be passed on ARM-based machine. There are still a lot
> of missing parts, such as hot loops, class/object/array operations,
> exception handling, etc, and we will continue working on them.
>
> We would like to share our work with you (See the draft patch
> https://github.com/shqking/php-src/commit/6aaf935).
> Any feedback would be greatly appreciated, and please let we know if
> anyone wants to contribute to this port.
>
> Thanks,
> Hao SUN
> Email: hao@arm.com
>
> ---
> Main updates:
> 1. JIT backend for AArch64
> A new alternative, i.e. AArch64, was added while building PHP JIT. See the
> updates in the following files. Note that we adopt capstone[2] for
> disassembly on AArch64.
>
>   build/Makefile.global
>   ext/opcache/config.m4
>   ext/opcache/config.w32
>   ext/opcache/jit/Makefile.frag
>   ext/opcache/jit/zend_jit.c
>   ext/opcache/jit/zend_jit_vm_helpers.c
>   ext/opcache/jit/zend_jit_disasm_arm64.c
>   ext/opcache/jit/zend_jit_gdb.c
>   ext/opcache/jit/zend_jit_perf_dump.c
>
> 2. DynASM library
> PHP JIT uses DynASM[3] (developed for LuaJIT project) to generate native
> code on the fly. We added two useful but missing features, global label
> reference and dynamic register names, into DynASM/arm64. See the updates
> in files:
>
>   ext/opcache/jit/dynasm/dasm_arm64.h
>   ext/opcache/jit/dynasm/dasm_arm64.lua
>
> Note that these two features are available on DynASM/x86.
>
> 3. compilation for opcodes on AArch64
> Our main work falls in the following files.
>
>   ext/opcache/jit/zend_jit_arm64.h
>   ext/opcache/jit/zend_jit_arm64.dasc
>   ext/opcache/jit/zend_jit_internal.h
>   Zend/zend_vm_opcodes.h
>
> * AArch64 registers and calling conventions are defined.
>
> * Instruction cache must be flushed for the JIT-ed code on AArch64. See
> macro JIT_CACHE_FLUSH in file 'zend_jit_internal.h'.
>
> * We have (partially) implemented the compilation for several opcodes,
> mainly for the function-based JIT (with opcache.jit=1203). Currently,
> test cases involving internal function call (e.g. var_dump), additions
> with integers/floating-point numbers, integer overflows and simple
> exception, can be supported now. See our newly added test cases under
> directory 'ext/opcache/tests/jit/arm64/'.
>
> * Trace counter stubs are implemented for tracing JIT (with
> opcache.jit=1255). See zend_jit_hybrid_trace_counter_stub() and
> zend_jit_hybrid_hot_trace_stub() in file 'zend_jit_arm64.dasc'. Hot
> functions can be recognized and compiled successfully. See the test case
> 'hot_func_002.phpt'.
>
> How to build and test:
> Our local test environment is an ARM-based server with Ubuntu 20.04 and
> GCC-10. We follow the building commands as shown in the readme file [4].
> Note that library capstone should be installed in advance.
>
> We suggest running the JIT test cases using the following command. In our
> local test, 59 out of all 128 cases can be passed currently.
>   $ make test TESTS='-d opcache.jit=1203 ext/opcache/tests/jit/'
>
> [1] https://wiki.php.net/rfc/jit
> [2] https://www.capstone-engine.org/
> [3] https://luajit.org/dynasm.html
> [4] https://github.com/php/php-src
>
>

Re: [PHP-DEV] Re: Recent changes to opcache cause crashes

[Dmitry Stogov]

This is fixed in master.

Thanks. Dmitry.

On Fri, Mar 5, 2021 at 4:43 PM Dennis Birkholz 
wrote:

> Hello,
>
> I was also able to reproduce the error.
>
> I used the latest available "daily" cloud image for Debian Buster and
> created a small recipe to reproduce. Hopefully this helps in finding the
> problem.
>
> Greets
> Dennis
>
>
> wget
> "
> https://cloud.debian.org/images/cloud/buster/20210208-542/debian-10-nocloud-amd64-20210208-542.tar.xz
> "
> tar -xvf "debian-10-nocloud-amd64-20210208-542.tar.xz"
>
> # Resized the image, 2GB is to small
> dd if=/dev/zero bs=1M count=1 seek=20479 of=disk.raw
> echo ", +" | /sbin/sfdisk -N 1 disk.raw
> sudo losetup -f --show disk.raw
> sudo partprobe /dev/loop0
> sudo e2fsck -f /dev/loop0p1
> sudo resize2fs /dev/loop0p1
> sudo losetup -d /dev/loop0
>
> # create and start VM, e.g. with virt-manager
>
> # Inside VM
> # Generate ssh host keys
> dpkg-reconfigure openssh-server
> # Change PermitRootLogin, PasswordAuthentication and
> PermitEmptyPasswords to yes to login without password/key
> systemctl restart sshd.service
>
> apt install git autoconf make gcc g++ pkg-config bison re2c libssl-dev
> libxml2-dev libsqlite3-dev zlib1g-dev libbz2-dev libcurl4-openssl-dev
> libpng-dev libjpeg-dev libonig-dev libreadline-dev libsodium-dev
> libxslt1-dev libzip-dev libffi-dev
>
> git clone https://github.com/php/php-src
> cd php-src
> ./buildconf
> ./configure  '--prefix=/usr/local/php/master' '--enable-debug'
> '--with-gettext' '--with-gd' '--enable-gd' '--with-jpeg'
> '--without-freetype' '--with-jpeg-dir=/usr' '--without-freetype-dir'
> '--with-mysql=mysqlnd' '--enable-bcmath' '--with-readline'
> '--with-openssl' '--without-esmtp' '--with-curl' '--with-sodium'
> '--with-ffi' '--with-mysqli' '--enable-pcntl' '--enable-sockets'
> '--enable-zip' '--with-zip' '--enable-memory-limit' '--with-mcrypt'
> '--with-libxml' '--enable-libxml' '--with-iconv' '--enable-wddx'
> '--enable-calendar' '--with-sqlite3' '--enable-spl' '--enable-pdo'
> '--with-pdo-mysql' '--with-pdo-sqlite' '--with-ctype' '--with-bz2'
> '--enable-mbstring' '--with-mime-magic' '--with-xmlrpc' '--with-zlib'
> '--disable-zend-memory-manager' '--with-esmtp' '--with-xsl'
> '--enable-exif' '--enable-soap' '--enable-ftp' '--enable-intl'
> '--enable-opcache' '--enable-fpm' '--enable-fileinfo' '--with-pear'
> make && make install
>
> cd ~
> wget
> "
> https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> "
> -O "xdebug_var_dump_typed_properties-text.php"
> /usr/local/php/master/bin/php -n -dzend_extension=opcache -d
> "opcache.enable=1" -d "opcache.enable_cli=1" -d
> "opcache.optimization_level=-1" -f
> xdebug_var_dump_typed_properties-text.php
>
>
> Am 04.03.21 um 19:14 schrieb Dmitry Stogov:
> > I suppose, something is wrong with your build.
> > This code works fine for me.
> > Please, try full rebuild.
> >
> > Thanks. Dmitry.
> >
> > On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:
> >
> >> Hi,
> >>
> >> turns out that this test fails even without Xdebug even loaded, so it's
> >> not something on my side :-)
> >>
> >> Just run it as:
> >>
> >> wget
> >>
> https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> >> -O xdebug_var_dump_typed_properties-text.php
> >> php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> >> "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> >> xdebug_var_dump_typed_properties-text.php
> >>
> >> Result:
> >>
> >> php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> >> zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> >> Aborted
> >>
> >>
> >> cheers,
> >> Derick
> >>
> >>
> >
>
>

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Dmitry Stogov]

On Thu, Mar 4, 2021 at 11:49 PM Derick Rethans  wrote:

> On 4 March 2021 20:22:37 GMT, Dmitry Stogov 
> wrote:
> >I can't reproduce this on Linux.
> >
> >[dmitry@tpl2 xdebug]$ php run-xdebug-tests.php -d opcache.enable=1 -d
> >opcache.enable_cli=1 -d opcache.optimization_level=-1
> >tests/tracing/functrace_typed_properties.phpt
> >
> >...
> >PHP_VERSION : 8.1.0-dev
> >...
> >PASS Test for function traces with typed properties
> >[tests/tracing/functrace_typed_properties.phpt]
> >...
>
>
> That's curious. I'm locally on Debian Linux, and Azure pipelines is on
> OSX. How can we figure this out? Want to do a screenshare or something?
> Perhaps it's a compiler issue? I'm building in debug mode FWIW. And see it
> with and without ZTS.


Do you use CLANG on Linux?
I won't be able to work on this before March 9.


>
>
> Did you try my one liner without xdebug involved at all too?
>

Everything works fine for me.
We test OSX build without xdebug on Azure, and didn't see a similar problem.

Thanks. Dmitry.


>
> cheers,
> Derick
>

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Dmitry Stogov]

I can't reproduce this on Linux.

[dmitry@tpl2 xdebug]$ php run-xdebug-tests.php -d opcache.enable=1 -d
opcache.enable_cli=1 -d opcache.optimization_level=-1
tests/tracing/functrace_typed_properties.phpt

...
PHP_VERSION : 8.1.0-dev
...
PASS Test for function traces with typed properties
[tests/tracing/functrace_typed_properties.phpt]
...

Thanks. Dmitry

On Thu, Mar 4, 2021 at 9:43 PM Derick Rethans  wrote:

> Hi,
>
> It's not just my own build, see this one on OSX on Azure Pipelines (line
> 427):
>
>
> https://dev.azure.com/php-xdebug/Xdebug/_build/results?buildId=388=logs=fa4207ea-b23d-55f8-a438-8fcfe0ff1a84=a376e1dc-bcfe-530b-98ce-61c964f8af0f=425
>
> Which is a build from scratch.
>
> And I've locally also just rebuild from scratch, but still getting the
> same result.
>
> My build log:
> http://derickrethans.nl/files/dump/master.log
>
> My configure line:
> './configure'  '--prefix=/usr/local/php/master' '--enable-debug'
> '--with-gettext' '--with-gd' '--enable-gd' '--with-jpeg'
> '--without-freetype' '--with-jpeg-dir=/usr' '--without-freetype-dir'
> '--with-mysql=mysqlnd' '--enable-bcmath' '--with-readline' '--with-openssl'
> '--without-esmtp' '--with-curl' '--with-sodium' '--with-ffi'
> '--with-mysqli' '--enable-pcntl' '--enable-sockets' '--enable-zip'
> '--with-zip' '--enable-memory-limit' '--with-mcrypt' '--with-libxml'
> '--enable-libxml' '--with-iconv' '--enable-wddx' '--enable-calendar'
> '--with-sqlite3' '--enable-spl' '--enable-pdo' '--with-pdo-mysql'
> '--with-pdo-sqlite' '--with-ctype' '--with-bz2' '--enable-mbstring'
> '--with-mime-magic' '--with-xmlrpc' '--with-zlib'
> '--disable-zend-memory-manager' '--with-esmtp' '--with-xsl' '--enable-exif'
> '--enable-soap' '--enable-ftp' '--enable-intl' '--enable-opcache'
> '--enable-fpm' '--enable-fileinfo' '--with-pear'
>
> cheers,
> Deric
>
> On Thu, 4 Mar 2021, Dmitry Stogov wrote:
>
> > I suppose, something is wrong with your build.
> > This code works fine for me.
> > Please, try full rebuild.
> >
> > Thanks. Dmitry.
> >
> > On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:
> >
> > > Hi,
> > >
> > > turns out that this test fails even without Xdebug even loaded, so it's
> > > not something on my side :-)
> > >
> > > Just run it as:
> > >
> > > wget
> > >
> https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> > > -O xdebug_var_dump_typed_properties-text.php
> > > php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> > > "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> > > xdebug_var_dump_typed_properties-text.php
> > >
> > > Result:
> > >
> > > php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> > > zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> > > Aborted
> > >
> > >
> > > cheers,
> > > Derick
> > >
> > >
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Dmitry Stogov]

I suppose, something is wrong with your build.
This code works fine for me.
Please, try full rebuild.

Thanks. Dmitry.

On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:

> Hi,
>
> turns out that this test fails even without Xdebug even loaded, so it's
> not something on my side :-)
>
> Just run it as:
>
> wget
> https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> -O xdebug_var_dump_typed_properties-text.php
> php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> xdebug_var_dump_typed_properties-text.php
>
> Result:
>
> php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> Aborted
>
>
> cheers,
> Derick
>
>

[PHP-DEV] Re: Recent changes to opcache cause crashes when loaded with Xdebug

[Dmitry Stogov]

We already made few significant changes in PHP-8.1.
e.g. most classes and methods are immutable.
It's not allowed to change them (this is the same as before, but now almost
all of them are immutable). Use opcache.protect_memory=1 to catch
potentially wrong modification.

>From the quick look, I don't see how zend_map_ptr_new() may return 0 or 1
at this point.
I'll be able to run xdebug tests only in the middle of the next week.

Thanks. Dmitry.

On Thu, Mar 4, 2021 at 3:41 PM Derick Rethans  wrote:

> Hi,
>
> I've been doing some work on making Xdebug run with PHP 8.1 (master)
> again, and after my fixes
> (https://github.com/xdebug/xdebug/pull/728/files) I am still running
> into a crash (or rather, assert, in opcache):
>
> php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
>
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x76bc5537 in __GI_abort () at abort.c:79
> #2  0x76bc540f in __assert_fail_base (fmt=0x76d2e128
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x745b7584 "ret
> > 2", file=0x745b7410
> "/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c",
> line=327, function=) at assert.c:92
> #3  0x76bd4662 in __GI___assert_fail (assertion=0x745b7584
> "ret > 2", file=0x745b7410
> "/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c", line=327,
> function=0x745b7810 <__PRETTY_FUNCTION__.6>
> "zend_accel_get_type_map_ptr") at assert.c:101
> #4  0x744a1328 in zend_accel_get_type_map_ptr
> (type_name=0x4021bbb0, scope=0x408beca0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327
> #5  0x744a15a2 in zend_persist_type (type=0x408bf068,
> scope=0x408beca0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:352
> #6  0x744a292a in zend_persist_op_array_ex (op_array=0x408bef00,
> main_persistent_script=0x0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:630
> #7  0x744a34de in zend_persist_class_method (zv=0x408beec0,
> ce=0x408beca0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:765
> #8  0x744a40f8 in zend_persist_class_entry
> (orig_ce=0x57324b28) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:876
> #9  0x744a7047 in zend_accel_persist_class_table
> (class_table=0x408beaf0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:1225
> #10 0x744a7845 in zend_accel_script_persist (script=0x408be9c0,
> key=0x7fff99e0, key_length=80, for_shm=1) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:1286
> #11 0x7448c2e3 in cache_script_in_shared_memory
> (new_persistent_script=0x5739a8b0, key=0x408beb88
> "coverage4.inc:2502976:2352312:/home/derick/dev/php/derickr-xdebug/tests/coverage",
> key_length=80,
> from_shared_memory=0x7fff9adc) at
> /home/derick/dev/php/php-src.git/ext/opcache/ZendAccelerator.c:1550
> #12 0x7448f3b2 in persistent_compile_file
> (file_handle=0x7fff9b80, type=2) at
> /home/derick/dev/php/php-src.git/ext/opcache/ZendAccelerator.c:2181
> #13 0x74402461 in xdebug_compile_file (file_handle=0x7fff9b80,
> type=2) at /home/derick/dev/php/derickr-xdebug/src/base/base.c:75
> #14 0x55d8bf25 in compile_filename (type=2, filename=0x408be620)
> at Zend/zend_language_scanner.l:727
> #15 0x55e31b86 in zend_include_or_eval (inc_filename=0x408be620,
> type=2) at /home/derick/dev/php/php-src.git/Zend/zend_execute.c:4270
> #16 0x55e40d13 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER () at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:4697
> #17 0x55e3ba87 in ZEND_USER_OPCODE_SPEC_HANDLER () at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:3019
> #18 0x55eabc4c in execute_ex (ex=0x57334b40) at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:54826
> #19 0x74404838 in xdebug_execute_ex (execute_data=0x57334b40)
> at /home/derick/dev/php/derickr-xdebug/src/base/base.c:765
> #20 0x55eb02b6 in zend_execute (op_array=0x571afcf0,
> return_value=0x0) at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:59065
> #21 0x55dfba96 in zend_execute_scripts (type=8, retval=0x0,
> file_count=3) at /home/derick/dev/php/php-src.git/Zend/zend.c:1689
> #22 0x55d4e84d in php_execute_script (primary_file=0x7fffd580)
> at /home/derick/dev/php/php-src.git/main/main.c:2489
> #23 0x55f5ad32 in do_cli (argc=88, argv=0x56fb0e10) at
> /home/derick/dev/php/php-src.git/sapi/cli/php_cli.c:964
> #24 0x55f5bd80 in main (argc=88, argv=0x56fb0e10) at
> 

[PHP-DEV] Re: timelib inefficiency

[Dmitry Stogov]

hi,

On Thu, Mar 4, 2021 at 3:30 PM Derick Rethans  wrote:

> Hi,
>
> I saw the PRs coming in, I'll reply inline:
>
> On Thu, 4 Mar 2021, Dmitry Stogov wrote:
>
> >
> https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58
>
> As Nikita already commented, this now seems to introduce flakeyness into
> tests.
>
> > And created 3 pull request for timelib:
> >
> > https://github.com/derickr/timelib/pull/98
>
> That looks reasonable. I'm currently working on implementing
> https://github.com/derickr/timelib/issues/14 which will also touch that
> code, so I'll look at it as part of that work.
>
> > https://github.com/derickr/timelib/pull/99
>
> Is incorrect, the tzfile 5 man page says:
>
> Time zone designations should consist of at least three (3) and no
> more
> than six (6) ASCII characters from the set of alphanumerics
>

timelib (timezonedb.h and fallbackmap.h) doesn't have abbreviation longer
than 5 characters, but has single char abbreviations.


>
> I am curious to as to why this routine was called so often though, as
> looking for abbreviations isn't something that should have be be done
> often.
>

Every time you parse a time zone name (including a date with timezone) you
always (except for UTS and GMT) perform a linear search through all entries
listed in timezonedb.h (1128 string comparisons + 1128*2 lowercasing +
1128*2 calls to strlen()), and only then take a look for timezone name,
that may be already cached.


>
> > https://github.com/derickr/timelib/pull/100
>
> This new routine is perhaps faster, but it is also extremely more
> complex, with little comments. It's unlikely I would want to incorporate
> it in its current form.
>

What comments do you like?
We first guess the year dividing days to 365, then check if our guess is
right (number of days from the start of the guessed year fits into this
year), and then continue searching.
This is like a binary search, but with base 365 and the rule to check the
leap year.


> > Please, verify and merge the timelib patches into PHP.
> > Please, let me know if this will take time.
>
> It will certainly take time :-)
>
> > I fixed only the visible, most significant and obvious bottlenecks.
> > It's possible to improve timelib more...
>
> I'm sure it is! The code is 17 years old by now!
>

yeah, this is the problem. Nobody likes to improve it. I'm interested only
because it significantly affects PHP performance.

Thanks. Dmitry.


>
> cheers,
> Derick
>

[PHP-DEV] Re: timelib inefficiency

[Dmitry Stogov]

Hi Derick,

I spent some time looking in the timelib implementation caused slowness in
the Symphony Demo app (https://github.com/symfony/demo)

I committed one patch into ext/date:

https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58

And created 3 pull request for timelib:

https://github.com/derickr/timelib/pull/98
https://github.com/derickr/timelib/pull/99
https://github.com/derickr/timelib/pull/100

These patches make 5% improvement on the Symphony Demo app (100 homepage
requests after warm up, according to callgrind, timezone "Europe/Moscow")

Please, verify and merge the timelib patches into PHP.
Please, let me know if this will take time.

I fixed only the visible, most significant and obvious bottlenecks.
It's possible to improve timelib more...

Thanks. Dmitry.

On Thu, Feb 25, 2021 at 3:21 PM Dmitry Stogov 
wrote:

> Hi Derick,
>
> Please take a look
>
>
> https://github.com/php/php-src/blob/51914610ab8bf75d87e5cdec15bd1b38de7907c5/ext/date/lib/parse_date.re#L684-L700
>
> This code is enormously inefficient. For a single abbr_search(), it calls
> timelib_strcasecmp() more than 1000 times (complete linear search in a huge
> almost ordered array, with repeatable and redundant lowercasing). 11 calls
> to abbr_search() per request in the Symfony Demo application (
> https://github.com/symfony/demo) eat 2% of overall CPU time.
>
> I see some other inefficient patterns in timelib. e.g. API design that
> leads to many useless heap allocations/deallocations; calloc() followed by
> memcpy(), etc
>
> Thanks. Dmitry.
>

[PHP-DEV] timelib inefficiency

[Dmitry Stogov]

Hi Derick,

Please take a look

https://github.com/php/php-src/blob/51914610ab8bf75d87e5cdec15bd1b38de7907c5/ext/date/lib/parse_date.re#L684-L700

This code is enormously inefficient. For a single abbr_search(), it calls
timelib_strcasecmp() more than 1000 times (complete linear search in a huge
almost ordered array, with repeatable and redundant lowercasing). 11 calls
to abbr_search() per request in the Symfony Demo application (
https://github.com/symfony/demo) eat 2% of overall CPU time.

I see some other inefficient patterns in timelib. e.g. API design that
leads to many useless heap allocations/deallocations; calloc() followed by
memcpy(), etc

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Dmitry Stogov]

+1

On Tue, Feb 23, 2021 at 5:02 PM Nikita Popov  wrote:

> Hi internals,
>
> While looking into various issues related to static variable handling, I've
> become increasingly convinced that our handling of static variables in
> inherited methods is outright buggy. However, it's also long-standing
> behavior, so I've put up an RFC:
>
> https://wiki.php.net/rfc/static_variable_inheritance
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Inheritance Cache

[Dmitry Stogov]

Hi Brent,

Preloading had intention to completely eliminate opcache overhead, but
because of limitations it wasn't able to preload classes with unresolved
constants, typed properties and covariant checks.

This PR makes these preloading limitations less strict and adds transparent
inheritance cache. Inheritance cache eliminates only part of redundancy, in
comparison to preloading. It should be a bit slower, but it will work out
of the box.

Thanks. Dmitry.

On Tue, Feb 9, 2021 at 8:40 AM Brent Roose  wrote:

> Hey Dmitry
>
> Out of curiousity: how does this compare to preloading? From what I
> understand preloading also links classes, which was one of the most
> important differences between preloading files and simply storing them in
> opcache. Does this change mean that preloading becomes much less relevant
> since class linking can now also happen at runtime?
>
> Kind regards
> Brent
>
> > On 5 Feb 2021, at 15:03, Dmitry Stogov  wrote:
> >
> > Hi,
> >
> > I'm glad to present the result of my recent work - Inheritance Cache.
> >
> > https://github.com/php/php-src/pull/6627
> >
> > This is a new transparent technology that eliminates overhead of PHP
> class
> > inheritance.
> >
> > PHP  classes are compiled and cached (by opcahce) separately, however
> their
> > "linking" was done at run-time - on each request. The process of
> "linking"
> > may involve a number of compatibility checks and borrowing
> > methods/properties/constants form parent and traits. This takes
> significant
> > time, but the result is the same on each request.
> >
> > Inheritance Cache performs "linking" for unique set of all the depending
> > classes (parent, interfaces, traits, property types, method types
> involved
> > into compatibility checks) once and stores result in opcache shared
> memory.
> > As a part of the this patch, I removed limitations for immutable classes
> > (unresolved constants, typed properties and covariant type checks). So
> now
> > all classes stored in opcache are "immutable". They may be lazily loaded
> > into process memory, if necessary, but this usually occurs just once (on
> > first linking).
> >
> > The patch shows 8% improvement on Symphony "Hello World" app.
> >
> > I'm going to merge this patch into master on next week.
> > Please review and give your comments.
> >
> > Thanks. Dmitry.
>
>

[PHP-DEV] Inheritance Cache

[Dmitry Stogov]

Hi,

I'm glad to present the result of my recent work - Inheritance Cache.

https://github.com/php/php-src/pull/6627

This is a new transparent technology that eliminates overhead of PHP class
inheritance.

PHP  classes are compiled and cached (by opcahce) separately, however their
"linking" was done at run-time - on each request. The process of "linking"
may involve a number of compatibility checks and borrowing
methods/properties/constants form parent and traits. This takes significant
time, but the result is the same on each request.

Inheritance Cache performs "linking" for unique set of all the depending
classes (parent, interfaces, traits, property types, method types involved
into compatibility checks) once and stores result in opcache shared memory.
As a part of the this patch, I removed limitations for immutable classes
(unresolved constants, typed properties and covariant type checks). So now
all classes stored in opcache are "immutable". They may be lazily loaded
into process memory, if necessary, but this usually occurs just once (on
first linking).

The patch shows 8% improvement on Symphony "Hello World" app.

I'm going to merge this patch into master on next week.
Please review and give your comments.

Thanks. Dmitry.

[PHP-DEV] Re: [PHP-CVS] com php-src: Remove mysqlnd_extension enum: ext/mysqli/mysqli.c ext/mysqli/mysqli_warning.c ext/mysqlnd/mysqlnd.h ext/mysqlnd/mysqlnd_enum_n_def.h ext/mysqlnd/mysqlnd_result.c

[Dmitry Stogov]

Hi Nikita,

ext/mysql is not a part of the main php source tree, but it still works and
is still useful.
Why do you kill it and why silently (may be I missed discussion)?
What is the motivation?

Thanks. Dmitry.


On Tue, Dec 15, 2020 at 12:58 PM Nikita Popov  wrote:

> Commit:362c29241db872cf7eb030cef1148d47d3489be1
> Author:Nikita Popov  Tue, 15 Dec 2020
> 10:55:53 +0100
> Parents:   be4f73f328f7aa85f1c893247b5007ce5f2c
> Branches:  master
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=362c29241db872cf7eb030cef1148d47d3489be1
>
> Log:
> Remove mysqlnd_extension enum
>
> ext/mysql is no longer supported, drop handling for it from
> mysqlnd.
>
> Changed paths:
>   M  ext/mysqli/mysqli.c
>   M  ext/mysqli/mysqli_warning.c
>   M  ext/mysqlnd/mysqlnd.h
>   M  ext/mysqlnd/mysqlnd_enum_n_def.h
>   M  ext/mysqlnd/mysqlnd_result.c
>   M  ext/mysqlnd/mysqlnd_structs.h
>
>
> Diff:
> diff --git a/ext/mysqli/mysqli.c b/ext/mysqli/mysqli.c
> index cea4ba63946..50c5038f157 100644
> --- a/ext/mysqli/mysqli.c
> +++ b/ext/mysqli/mysqli.c
> @@ -1130,7 +1130,7 @@ void php_mysqli_fetch_into_hash_aux(zval
> *return_value, MYSQL_RES * result, zend
> }
> }
>  #else
> -   mysqlnd_fetch_into(result, ((fetchtype & MYSQLI_NUM)?
> MYSQLND_FETCH_NUM:0) | ((fetchtype & MYSQLI_ASSOC)? MYSQLND_FETCH_ASSOC:0),
> return_value, MYSQLND_MYSQLI);
> +   mysqlnd_fetch_into(result, ((fetchtype & MYSQLI_NUM)?
> MYSQLND_FETCH_NUM:0) | ((fetchtype & MYSQLI_ASSOC)? MYSQLND_FETCH_ASSOC:0),
> return_value);
>  #endif
>  }
>  /* }}} */
> diff --git a/ext/mysqli/mysqli_warning.c b/ext/mysqli/mysqli_warning.c
> index 7b1552e5ace..6dd7090911e 100644
> --- a/ext/mysqli/mysqli_warning.c
> +++ b/ext/mysqli/mysqli_warning.c
> @@ -131,7 +131,7 @@ MYSQLI_WARNING * php_get_warnings(MYSQLND_CONN_DATA *
> mysql)
> zval *entry;
> int errno;
>
> -   mysqlnd_fetch_into(result, MYSQLND_FETCH_NUM, ,
> MYSQLND_MYSQLI);
> +   mysqlnd_fetch_into(result, MYSQLND_FETCH_NUM, );
> if (Z_TYPE(row) != IS_ARRAY) {
> zval_ptr_dtor();
> break;
> diff --git a/ext/mysqlnd/mysqlnd.h b/ext/mysqlnd/mysqlnd.h
> index bf3a9d640fa..b4d3d1f8c33 100644
> --- a/ext/mysqlnd/mysqlnd.h
> +++ b/ext/mysqlnd/mysqlnd.h
> @@ -98,7 +98,7 @@ PHPAPI MYSQLND * mysqlnd_connection_connect(MYSQLND *
> conn,
>  PHPAPI void mysqlnd_debug(const char *mode);
>
>  /* Query */
> -#define mysqlnd_fetch_into(result, flags, ret_val, ext)
> (result)->m.fetch_into((result), (flags), (ret_val), (ext)
> ZEND_FILE_LINE_CC)
> +#define mysqlnd_fetch_into(result, flags, ret_val)
>  (result)->m.fetch_into((result), (flags), (ret_val) ZEND_FILE_LINE_CC)
>  #define mysqlnd_fetch_row_c(result)
>   (result)->m.fetch_row_c((result))
>  #define mysqlnd_fetch_all(result, flags, return_value)
> (result)->m.fetch_all((result), (flags), (return_value) ZEND_FILE_LINE_CC)
>  #define mysqlnd_get_connection_stats(conn, values)
>  ((conn)->data)->m->get_statistics((conn)->data,  (values)
> ZEND_FILE_LINE_CC)
> diff --git a/ext/mysqlnd/mysqlnd_enum_n_def.h
> b/ext/mysqlnd/mysqlnd_enum_n_def.h
> index 161a3821bd2..191b8388b34 100644
> --- a/ext/mysqlnd/mysqlnd_enum_n_def.h
> +++ b/ext/mysqlnd/mysqlnd_enum_n_def.h
> @@ -148,12 +148,6 @@
>  #define TRANS_COR_RELEASE  4
>  #define TRANS_COR_NO_RELEASE   8
>
> -typedef enum mysqlnd_extension
> -{
> -   MYSQLND_MYSQL = 0,
> -   MYSQLND_MYSQLI
> -} enum_mysqlnd_extension;
> -
>  enum
>  {
> MYSQLND_FETCH_ASSOC = 1,
> diff --git a/ext/mysqlnd/mysqlnd_result.c b/ext/mysqlnd/mysqlnd_result.c
> index bdeefd5d04d..f67f8bdcc17 100644
> --- a/ext/mysqlnd/mysqlnd_result.c
> +++ b/ext/mysqlnd/mysqlnd_result.c
> @@ -1692,8 +1692,7 @@ MYSQLND_METHOD(mysqlnd_res, field_tell)(const
> MYSQLND_RES * const result)
>  /* {{{ mysqlnd_res::fetch_into */
>  static void
>  MYSQLND_METHOD(mysqlnd_res, fetch_into)(MYSQLND_RES * result, const
> unsigned int flags,
> -
>  zval *return_value,
> -
>  enum_mysqlnd_extension extension ZEND_FILE_LINE_DC)
> +
>  zval *return_value ZEND_FILE_LINE_DC)
>  {
> zend_bool fetched_anything;
> unsigned int array_size;
> @@ -1715,15 +1714,7 @@ MYSQLND_METHOD(mysqlnd_res, fetch_into)(MYSQLND_RES
> * result, const unsigned int
> RETVAL_FALSE;
> } else if (fetched_anything == FALSE) {
> zend_array_destroy(Z_ARR_P(return_value));
> -   switch (extension) {
> -   case MYSQLND_MYSQLI:
> -   RETVAL_NULL();
> -   break;
> -   case MYSQLND_MYSQL:
> -   RETVAL_FALSE;
> -   break;
> -   default:exit(0);
> -   }
> +   RETVAL_NULL();
> }
> /*
>   return_value is IS_NULL for no more data 

Re: [PHP-DEV] ZEND_ENGINE_4

[Dmitry Stogov]

We don't need ZEND_ENGINE_4 for PHP 8.*.
PHP 8.0 didn't introduce revolutionary engine changes (like PHP 7 and PHP 5
did), and we won't introduce big engine changes in minor releases.

Thanks. Dmitry.

On Thu, Nov 26, 2020 at 11:44 AM Remi Collet  wrote:

> Le 26/11/2020 à 03:41, Sara Golemon a écrit :
> > Maybe just a wee bit late to ask this question, but shouldn't we have
> long
> > since changed `#define ZEND_ENGINE_3` to `#degine ZEND_ENGINE_4` ?
>
>  From a quick search I see some usage of ZEND_ENGINE_3
> (eg, imagick and gmagick ext, probably others)
>
> > Was that deliberate since (unlike with 4->5 and 5->7) the engine's API
> > surface area hasn't skewed so bad?
>
> Indeed,
>
> This is mostly used to test for PHP 5 vs 7/8 API
>
> >
> > I ask because ZEND_VERSION did get updated to the 4.x.x series.
>
> IMHO, we should keep ZEND_ENGINE_3 to not break things so late
> and encourage dev to not use it anymore
>
> And drop it in 8.1 (without ZEND_ENGINE_4)
>
> Remi
>
> >
> > -Sara
> >
>
>
> P.S. https://github.com/Imagick/imagick/pull/363
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Dmitry Stogov]

On Tue, Nov 24, 2020 at 6:14 PM Sara Golemon  wrote:

> On Tue, Nov 24, 2020 at 8:55 AM Sara Golemon  wrote:
>
>> Given that the JIT is enabled by default, I'm tempted to add another RC
>> and delay the release.
>>
>>
> As Niki just helpfully pointed out; My understanding of the JIT's setting
> on 8.0 is wrong.  It's "on", but with a 0-sized buffer, so it's effectively
> disabled.
> #1 I feel so much more secure in this whole release than I did five
> minutes ago. No offence. :)
> #2 We can afford to be a little lax on pulling in those cherry-picks.
>
> So now the question is what is the impact of (not) pulling them into the
> release at the literal last minute.
> On the one hand, by the book, this is too late for a non-security fix.  On
> the other hand, this is .0, and it's impacting a not-enabled-by-default
> path, so we can be more generous.
>
>

I think many people are going to try JIT in PHP-8.0.0. The last commits fix
incorrect behavior of JIT generated code on some edge cases. e.g. wrong
reference-counting and following use-after-free on PHPUnit tests. Releasing
PHP-8.0.0 with already fixed bugs would cause false reports. On the other
hand the risk of these commits is minimal.

Thanks. Dmitry.


> Right now I'm inclined to pull them in, but I'll wait a few hours for
> anyone who wishes to object. (It's still only 9am here :p )
>
> -Sara
>

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Dmitry Stogov]

Hi Sara,

On Tue, Nov 24, 2020 at 5:56 PM Sara Golemon  wrote:

> On Tue, Nov 24, 2020 at 12:35 AM Dmitry Stogov 
> wrote:
>
>> I finally fixed all the known JIT related issues and made the PHP-8.0
>> build "green".
>>
>>
>> https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088=results
>>
>> Please, cherry-pick the following 5 commits into PHP-8.0.0.
>>
>> c8df28d276c25c6f5ad0f1ab2727804b32be8cfe
>> c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4
>> 4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5
>> 586ccfdfd5179336dcf3719577b8258e55e7d76e
>> 337d2af6ca50a52864034446d863331cbc61885e
>>
>>>
>>>
> Hi Dmitry, that's great news.
>
> Given that the JIT is enabled by default, I'm tempted to add another RC
> and delay the release.
> As the person who did this work, can you reassure my worries and tell me
> that's not needed?
> The good news is that none of these commits look particularly complex.
>

I think, new RC is not necessary.
These commits only affect JIT. They fix the recently found problems and
don't show any degradation.

Thanks. Dmitry.




>
> -Sara
>
> c8df28d276 Fixed 32-bit JIT
> c0d1dbcb43 Fixed incorrect TRACE_FRAME_MASK_NESTED flag setting
> 4cf3da7383 Keep value of register before possible side exit
> 586ccfdfd5 Fixed use-after-free in PHPUnit tests
> 337d2af6ca zend_jit_trace_stack_frame.stack can't be NULL
>

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Dmitry Stogov]

Hi,

I finally fixed all the known JIT related issues and made the PHP-8.0 build
"green".

https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088=results

Please, cherry-pick the following 5 commits into PHP-8.0.0.

c8df28d276c25c6f5ad0f1ab2727804b32be8cfe
c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4
4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5
586ccfdfd5179336dcf3719577b8258e55e7d76e
337d2af6ca50a52864034446d863331cbc61885e

Thanks. Dmitry.

On Thu, Nov 19, 2020 at 5:50 PM Sara Golemon  wrote:

> I've just cut the release branch for PHP-8.0.0 final which will be released
> in one week on 26 Nov.  Minor bug fixes can continue to be merged via the
> PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what
> 8.0.0RC5 contained unless serious issues are encountered.
>
> If you feel you have a fix which should be included in the 8.0.0 final
> release, please let Gabriel and I know which commit you would like
> cherry-picked onto that release spur.
>
> Please also help me out by reviewing the NEWS, UPGRADING, and
> UPGRADING.INTERNALS files: https://github.com/php/php-src/blob/PHP-8.0.0/
>
> Lastly, there are likely still gaps in the documentation of new features,
> so please take a moment away from code to make the manual better.
>
> -Sara
>

[PHP-DEV] Re: [PHP-CVS] com php-src: Don't force rebuild of symbol table, when populating $http_response_header variable by the HTTP stream wrapper: NEWS UPGRADING ext/standard/http_fopen_wrapper.c

[Dmitry Stogov]

Hi Derick,

On Thu, Oct 29, 2020 at 2:18 PM Derick Rethans  wrote:

> Hi Dmitry,
>
> what is the reason for this change? It breaks some introspection code
> that I am working on that expects the http_response_header variable to
> always be set for stream wrappers, even if it's not used in code.
>

$http_response_heade makes a lot of troubles for optimization, JIT and
performance.
It's already proposed to deprecate it in 8.1

I changed the behavior, because I just found a problem that can't be fixed
without performance loss.
The current JIT implementation would just leak memory if
$http_response_header is not used but magically created.
We discussed this with Nikita and decided to be practical and don't
populate $http_response_header if it's not used in function scope.

If EX(symbol_table) already exists, $http_response_header is going to be
created as before.
If you show your code, I might try to find a workaround for you.


>
> As this is a late behavioural changes, I am also wondering whether this
> should have been introduced so late in the RC process.
>

Yeah, I'm not a big fan of breaking things :(

Thanks. Dmitry.




Thanks. Dmitry.


>
> cheers,
> Derick
>
>
> On Wed, 28 Oct 2020, Dmitry Stogov wrote:
>
> > Commit:    2693f799be862bcaddd4204c10fb1e82156bb603
> > Author:Dmitry Stogov  Wed, 28 Oct 2020
> 12:59:00 +0300
> > Parents:   47a56208f0902ecb95d879197a7ed9a3ca9a7e61
> > Branches:  PHP-8.0 master
> >
> > Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=2693f799be862bcaddd4204c10fb1e82156bb603
> >
> > Log:
> > Don't force rebuild of symbol table, when populating
> $http_response_header variable by the HTTP stream wrapper
> >
> > Changed paths:
> >   M  NEWS
> >   M  UPGRADING
> >   M  ext/standard/http_fopen_wrapper.c
> >
> >
> > Diff:
> > diff --git a/NEWS b/NEWS
> > index 6030664f35c..1c3eee15354 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -2,6 +2,10 @@ PHP
> NEWS
> >
> |||
> >  ?? ??? , PHP 8.0.0RC4
> >
> > +- Standard:
> > +
> > +  . Don't force rebuild of symbol table, when populating
> $http_response_header
> > +variable by the HTTP stream wrapper. (Dmitry)
> >
> >  29 Oct 2020, PHP 8.0.0RC3
> >
> > diff --git a/UPGRADING b/UPGRADING
> > index 1a270ba4155..579424fbef4 100644
> > --- a/UPGRADING
> > +++ b/UPGRADING
> > @@ -617,6 +617,8 @@ PHP 8.0 UPGRADE NOTES
> >. substr(), mb_substr(), iconv_substr() and grapheme_substr() now
> consistently
> >  clamp out-of-bounds offsets to the string boundary. Previously,
> false was
> >  returned instead of the empty string in some cases.
> > +  . Populating $http_response_header variable by the HTTP stream wrapper
> > +doesn't force rebuilding of symbol table anymore.
> >
> >  - Sysvmsg:
> >. msg_get_queue() will now return an SysvMessageQueue object rather
> than a
> > diff --git a/ext/standard/http_fopen_wrapper.c
> b/ext/standard/http_fopen_wrapper.c
> > index 50758ad0f4a..d865d7e2f97 100644
> > --- a/ext/standard/http_fopen_wrapper.c
> > +++ b/ext/standard/http_fopen_wrapper.c
> > @@ -981,7 +981,7 @@ php_stream
> *php_stream_url_wrap_http(php_stream_wrapper *wrapper, const char *pa
> >
> >   if (!Z_ISUNDEF(headers)) {
> >   if (FAILURE == zend_set_local_var_str(
> > - "http_response_header",
> sizeof("http_response_header")-1, , 1)) {
> > + "http_response_header",
> sizeof("http_response_header")-1, , 0)) {
> >   zval_ptr_dtor();
> >   }
> >   }
> >
> >
> > --
> > PHP CVS Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Dmitry Stogov]

Hi,

This is fine to me.
I stopped active JIT development, and going to do only fixes and may be
minor improvements.

Thanks. Dmitry.

On Mon, Sep 28, 2020 at 11:56 AM Gabriel Caruso 
wrote:

> Following Sara's email a couple of weeks ago, I come this week with a
> similar one:
>
> Next Tuesday, Sep 29th, has been marked on our calendars as the branch date
> for PHP-8.0 which would open master up for 8.1 targeted work.
>
> This would mean that bug fixes would need to include PHP-8.0 in their merge
> chain (meaning more work to merge 8.0 targeted fixes).
>
> Please let Sara and I know how you feel about this date. We can see that
> master is still quite active, especially with
> https://github.com/php/php-tasks/issues/18 and
> https://github.com/php/php-tasks/issues/16, and we don't wish to make the
> work to stabilize
> the 8.0 release any more difficult than it has to be.
>
> Thanks,
>

Re: [PHP-DEV] PHP 8.0 branch cut

[Dmitry Stogov]

This also gives me a time frame to clean up JIT code without hurry.
I plan to separate the common JIT code, and merge JIT and VM helpers.

Thanks. Dmitry.

On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:

> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov  wrote:
>
> > On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
> >
> >> Next Tuesday, Sep 15th, has been marked on my calendar as the branch
> date
> >> for PHP-8.0 which would open master up for 8.1 targeted work.
> >>
> >> This would mean that bug fixes would need to include PHP-8.0 in their
> >> merge
> >> chain (meaning more work to merge 8.0 targeted fixes).
> >>
> >> Please let Gabriel and I know how you feel about this date.  I can see
> >> that
> >> master is still quite active, and I don't wish to make the work to
> >> stablize
> >> the 8.0 release any more difficult than it has to be.
> >>
> >>
> >
> > I think it would be good to make this week's release beta4 rather than
> rc1
> > (without affecting the rest of the schedule). In that case we'd also push
> > back the branching and final ABI freeze two weeks.
> >
> > We're close to done with the warning to Error exception promotion task,
> > but haven't really started on reviewing and consolidating parameter names
> > yet (in preparation for named parameters). It would be good to have that
> > work mostly finalized before RC1, so we can limit the number of nominally
> > BC-breaking changes past RC1 (I expect we'll still fix some things that
> > slipped through the cracks, but at least we should prevent any mass
> > changes).
> >
> >
> Yep. This seems like a reasonable adjustment to the schedule in order to
> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
> plan for RC1 branching in two weeks.  Wiki (
> https://wiki.php.net/todo/php80 )
> has been updated to reflect this.  Note that I have NOT moved the GA date
> at this time, as that would push us into Dec 10th.  Though as the date
> approaches we may decide to add RC5 back in for safety despite the
> perinavidinal timing.
>
> -Sara
>
> P.S. Yes, I made that word up. You know which one.
>

Re: [PHP-DEV] Re: @@Jit Attribute Considerations

[Dmitry Stogov]

My solution:

- remove doc-comment trigger. It doesn't make sense.
- add @@Jit("off") only. Later we may extend this.


On Tue, Aug 4, 2020 at 11:11 AM Benjamin Eberlei 
wrote:

> On Mon, Aug 3, 2020 at 7:44 PM Benjamin Eberlei 
> wrote:
>
> > Hi,
> >
> > I am going to pick up a discussion from
> > https://github.com/php/php-src/pull/5915 about the @@Jit attribute.
> >
> > Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
> > attribute and asked to discuss here.
> >
> > The reason is that the default tracing JIT is clever to decide itself
> when
> > to JIT or not, better not interfere with that. In case you run the
> tracing
> > JIT, only @@Jit("off") has an effect the others @@Jit("tracing") and
> > @@Jit("function") get ignored.
> >
> > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> > and "function". This trigger mode feels like micro-management for
> > developers and since it has virtually no spotlight in discussions and
> blog
> > posts about the JIT at the moment, we don't know if it brings benefits.
> >
> > Maybe for now it would be better to remove docblock / attribute support
> > for the JIT, and take a new attempt at it in 8.1? That prevents us from
> > rolling something we regret having to maintain later.
> >
>
> I updated the PR https://github.com/php/php-src/pull/5915 with the
> following things:
>
> - Removed attribute trigger mode for now.
> - Removed obsolete doc comment trigger mode
> - Add @@Jit("off") to disable JIT for an op_array or script
>
> Open questions:
> - Are we ok with removing @Jit("on"), @@Jit("tracing") and
> @@Jit("function") for now to thoroughly discuss best approach for 8.1?
> - Rename @@Jit to something more specific like @@JitOptions or @@JitHint?
> - Remove the attribute trigger constant 4, and move tracing JIT to use 4
> instead of 5?
>
> Outlook:
>
> We need to think about what the @@Jit attribute should actually mean in
> context of the function or tracing JIT. Personally it probably means
> "Always Jit this function regardless of hot counter or tracing results".
> I believe we don't need the attributes trigger mode, as everything happens
> either in context of function or tracing JIT.
>
>
> > greetings
> > Benjamin
> >
>

Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods

[Dmitry Stogov]

Does this RFC support __get() returning by reference?
See
https://github.com/php/php-src/blob/master/Zend/tests/overloaded_prop_assign_op_refs.phpt#L11

Thanks. Dmitry.

On Mon, Jun 1, 2020 at 12:20 AM Gabriel Caruso 
wrote:

> On Sun, 31 May 2020 at 15:57, Nikita Popov  wrote:
>
> > On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso <
> carusogabrie...@gmail.com>
> > wrote:
> >
> >> Hello, internals!
> >>
> >> I have opened the voting for
> >> https://wiki.php.net/rfc/magic-methods-signature.
> >>
> >> The voting period ends on 2020-06-19 at 18h (CEST).
> >>
> >
> > The RFC is a bit unclear on what is actually being proposed. It says
> >
> > > This RFC proposes to add parameter and return types checks per the
> > following details.
> >
> > and goes on to list (reasonable looking) magic method signatures, but
> does
> > not say how exactly those types are going to be checked. Is this going to
> > require exactly the same signature, or is this going to be in accordance
> > with variance rules? For example, are all of the following signatures
> valid
> > under this RFC? Only the first two? None of them?
> >
> > // Narrowed return type from ?array
> > public function __debugInfo(): array {}
> >
> > // Narrowed return type from mixed
> > public function __get(string $name): int {]
> >
> > // Widened argument type from string
> > public function __get(string|array $name): mixed {}
> >
>
>
> They are going to be checked following the variance rules, not the
> *exactly* same as the RFC. I'll mention this, thanks for point it out.
>
> Assuming this, your examples:
>
> 1 and 2. Will be valid, following the rules introduced by the `mixed` RFC.
>
> 3. Is that allowed in PHP? If so, the RFC will compliance with that.
>
>
> >
> > Also, is omitting the return type still permitted, even though it would
> > nominally violate variance?
> >
> > public function __debugInfo() {}
> >
>
> Yes, this hasn't changed. The RFC only affects *typed* methods.
>
>
> >
> > Finally, if omitting the return type is permitted, will an implicit
> return
> > type be added, like we do for __toString()? Would the method
> automatically
> > become
> >
> > public function __debugInfo(): ?array {}
> >
>
> An implicit return type won't be added for any of the magic methods. I
> believe that's a huge BC, and I don't want to debate that for PHP 8 (maybe
> PHP 9, yes).
>
>
> >
> > and report as such from reflection?
> >
>
> I need more clearance on this one: are you asking how magic methods are
> reported via Reflection and if that will be changed?
>
>
> >
> > Nikita
> >
>

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Dmitry Stogov]

Hi Dik,

On 11/3/19 12:44 AM, Dik Takken wrote:
> On 25-10-19 12:22, Nikita Popov wrote:
>> For reference, here are the results I get with/without JIT:
>> https://gist.github.com/nikic/2a2d363fffaa3aeb251da976f0edbc33
> 
> I toyed a bit with the benchmark script (union_bench.php) as well and
> wanted to share some observations. First of all I noticed the benchmark
> script has a typo on line 90 where it is calling the wrong function. It
> should read:
> 
>func6(1, 2, 3, 4, 5);
> 
> When running the corrected script I see that adding 5 argument type
> checks and a return type check cause almost 4x slowdown. My results
> (with opcache / jit):
> 
> func($a,$b,$c,$d,$e)   0.6800.583
> func(int $a,$b,$c,$d,$e): int  2.1062.009

Thanks for catching this. At least, now I see 2 times slowdown without 
JIT, that I expected, but didn't see.

func($a,$b,$c,$d,$e)   1.7461.555
func(int $a,$b,$c,$d,$e): int  3.6473.455

JIT will able to eliminate type checks only if it exactly knows the 
called function at caller site. Unfortunately, this is quite rare case, 
because the functions may be declared in different files, OOP, type 
variance, etc.

> 
> However, this appears to be entirely due to the return type check
> lacking a JIT implementation, as pointed out by Nikita. Adding one more
> test to the benchmark shows this nicely:
> 
> func($a,$b,$c,$d,$e)   0.6750.575
> func(int $a,$b,$c,$d,$e)   0.5740.475
> func(int $a,$b,$c,$d,$e): int  2.1062.009
> 
> Now we can see that the argument type hint actually improves
> performance, I guess due to it narrowing down the number of possible
> types that need to be considered for the function arguments.
> 
> Union types allow for more accurate type hinting as well as type hinting
> in places where this is currently not possible. As a result union types
> can be used to obtain performance gains. As an example, consider the
> case where the return type hint matches the type information that
> opcache has inferred about the variable that is returned. In that case,
> the return type check is optimized away. Let us try and leverage union
> types to make this happen. From the benchmark script we take func6:
> 
>function func6(int $a, int $b, int $c, int $d, int $e) : int {
>return $a + $b + $c + $d + $e;
>}
> 
> and adjust it to read:
> 
>function func6(int $a, int $b, int $c, int $d, int $e) : int|float {
>return $a + $b + $c + $d + $e;
>}
> 
> Now the return type hint matches what opcache infers the result of the
> expression will be and the cost of return type checking disappears
> completely:
> 
> func($a,$b,$c,$d,$e) 0.6630.568
> func(int $a,$b,$c,$d,$e) 0.5740.475
> func(int $a,$b,$c,$d,$e): int|float  0.5610.466
> 
> Then, on to another observation. The SSA forms currently produced by
> opcache show union types like string|int. This suggests that opcache
> supports union types for type inference already. It explains why opcache
> can nicely optimize type checks away even when union types are used.
> 
> This is not true for unions of classes though. A union type like int|Foo
> copies into the SSA form just fine while Foo|Bar becomes 'object'. Code
> like this:
> 
>class Foo {}
>class Bar {}
> 
>function func(): Foo|Bar {
>return new Foo();
>}
> 
>func();
> 
> produces the following SSA form:
> 
>func: ; (lines=4, args=0, vars=0, tmps=1, ssa_vars=2, no_loops)
>; (before dfa pass)
>; /php-src/sapi/cli/test.php:6-8
>; return  [object]
>BB0: start exit lines=[0-3]
>; level=0
>#0.V0 [object (Foo)] = NEW 0 string("Foo")
>DO_FCALL
>VERIFY_RETURN_TYPE #0.V0 [object (Foo)] -> #1.V0 [object]
>RETURN #1.V0 [object]
> 
> which will still perform a return type check even though the return type
> hint matches the actual type of the variable. Apparently the union type
> support in opcache is present but incomplete.
> So, while union types can incur higher type checking cost they also
> provide more powerful means to help type inference and improve
> performance. As opcache improves over time I think we can expect the
> cost to decrease while the gain increases. Or am I too optimistic here?

In my experience, static optimizations are not able to eliminate most 
type checks in PHP. Probably, if we developed more complete type-system 
and used type declaration everywhere we could achieve better results.
Introducing more type checks and more complex rules will increase 
run-time overhead.

I'm currently working on attempt of speculative optimizations based on 
run-time feedback, and the results might change the whole picture a bit.

Anyway, I'm especially against of mixing multiple classes in unions, not 
because of performance, but because of complex rules of method 
inheritance compatibility checks in 

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Dmitry Stogov]

Removing references would be great for implementation  , but this doesn't look 
realistic in context of PHP language.
HHVM already made steps into this direction with Hack.

Thanks. Dmitry.


From: Dan Ackroyd 
Sent: Friday, October 25, 2019 18:40
To: Dmitry Stogov 
Cc: Nikita Popov ; PHP internals 
Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2

On Fri, 25 Oct 2019 at 14:27, Dmitry Stogov  wrote:
>
> // <= 100 type checks on a single assignment

That code contains a reference that is re-used 100 times.

I personally prefer not to use references at all, but if people do
want to use them, we could put a note that references are bad for
performance when used with types. People can then choose between:

* using types, and not references for good performance.
* using references, and not types for good performance.
* using references and types, and getting slightly less good performance.

> I don't like to complicate the language with features
> that shouldn't be often used,

Can we start the discussion about deprecating references in PHP 8 then?

Very few people are writing code using them currently, and they seem
to cause quite a lot of confusion, judging by the bug reports about
them. If you're also saying that they are making it difficult to write
performant PHP, that seems to be a good argument for looking at what
would be needed to be done to remove them.

cheers
Dan
Ack


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Dmitry Stogov]

Hi Nikita,

in your results, assignment to typed reference is ~3 time slower without JIT 
and ~10 times slower with JIT.
But this is not the worst case. I can simple craft a script where single 
assignment will lead to  hundreds type checks.

ref =& $ref;
   }
}
for ($i = 0; $i < 100; $i++) {
   $a[$i] = new A($ref);
}
$ref = new A; // <= 100 type checks on a single assignment
?>

In case we add union types, we can make 200, 300 check...

The worst thing, for me, is variance together with union of multiple class 
types.
Each such method compatibility check is going to be a puzzle solving, and I 
imagine people, proud of writing "complex pearls".

My main concern, I don't like to complicate the language with features that 
shouldn't be often used, and I don't like to complicate implementation and 
reduce performance without real need.

In my opinion, union of standard types and single class or null should be 
enough for most typing use cases.

Thanks. Dmitry.

From: Nikita Popov 
Sent: Friday, October 25, 2019 13:22
To: Dmitry Stogov 
Cc: PHP internals 
Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2

On Wed, Oct 23, 2019 at 5:42 PM Dmitry Stogov 
mailto:dmi...@zend.com>> wrote:
Hi Nikita,

I checked the Union Type implementation, and it more or less good. I mean, it 
implements the RFC in almost the best way.
However, as I don't like the RFC itself. Especially, unions of multiple classes 
and interference with type variance, I'll vote against this.

Actually, I think PHP already took wrong direction implementing "typed 
references" and "type variance".
Introducing more "typing", we suggest using it, but this "typing" comes with a 
huge cost of run-time checks.
>From 10% (scalar type hint of argument) to 3 times (typed reference 
>assignment) performance degradation.
Anyone may rerun my benchmarks 
https://gist.github.com/dstogov/fb32023e8dd55e58312ae0e5029556a9

Thanks. Dmitry.

For reference, here are the results I get with/without JIT: 
https://gist.github.com/nikic/2a2d363fffaa3aeb251da976f0edbc33

I think that union types don't really change much in terms of the performance 
calculus of type checking, because type checking is equally fast (or slow) for 
a single scalar type, and 5 different scalar types: they are all handled in a 
single bit check. The only case that is indeed somewhat slow is if multiple 
class types are used in the union, because we actually have to check each one 
until we find a match. I do hope that having unions with a large number of 
classes will not be common.

Generally, this area could use some more optimization from the implementation 
side. I spent a bit of time yesterday optimizing how we perform instanceof 
checks (the implementation was quite inefficient, especially for interfaces), 
which had a large positive impact on class type checks. There's more low 
hanging fruit like this, for example verify_return_type has no JIT 
implementation yet (which is why with JIT simple arg type checks have nearly 
zero overhead, while return type checks have a large overhead). Assignments to 
typed properties are also badly optimized, because everything is punted to the 
slow path, while we should be able to handle the simple cases with just one 
extra bit check, without going through the complex implementation that deals 
with things like weak typing coercions.

I do think that performance considerations are important when it comes to new 
typing features (which is why, for example, we have categorically rejected a 
"typed arrays" implementation that has to check all array elements), but don't 
see union types are particular problematic in that regard, beyond what we 
already have.

Nikita


From: Dmitry Stogov mailto:dmi...@zend.com>>
Sent: Tuesday, October 22, 2019 15:38
To: Nikita Popov mailto:nikita@gmail.com>>; PHP 
internals mailto:internals@lists.php.net>>
Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2

Hi Nikita,

Can you please give me one/two days, before starting the voting, for 
implementation review (at least until October 25),

Thanks. Dmitry.


From: Nikita Popov mailto:nikita@gmail.com>>
Sent: Tuesday, October 22, 2019 12:36
To: PHP internals mailto:internals@lists.php.net>>
Subject: [PHP-DEV] Re: [RFC] Union Types v2

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov 
mailto:nikita@gmail.com>> wrote:

> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. 

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Dmitry Stogov]

Hi Nikita,

I checked the Union Type implementation, and it more or less good. I mean, it 
implements the RFC in almost the best way.
However, as I don't like the RFC itself. Especially, unions of multiple classes 
and interference with type variance, I'll vote against this.

Actually, I think PHP already took wrong direction implementing "typed 
references" and "type variance".
Introducing more "typing", we suggest using it, but this "typing" comes with a 
huge cost of run-time checks.
>From 10% (scalar type hint of argument) to 3 times (typed reference 
>assignment) performance degradation.
Anyone may rerun my benchmarks 
https://gist.github.com/dstogov/fb32023e8dd55e58312ae0e5029556a9

Thanks. Dmitry.

____
From: Dmitry Stogov 
Sent: Tuesday, October 22, 2019 15:38
To: Nikita Popov ; PHP internals 
Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2

Hi Nikita,

Can you please give me one/two days, before starting the voting, for 
implementation review (at least until October 25),

Thanks. Dmitry.


From: Nikita Popov 
Sent: Tuesday, October 22, 2019 12:36
To: PHP internals 
Subject: [PHP-DEV] Re: [RFC] Union Types v2

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>
> Relatively to the previous proposal by Bob (
> https://wiki.php.net/rfc/union_types), I think the main differences in
> this proposal are:
>  * Updated to specify interaction with new language features, like full
> variance and property types.
>  * Updated for the use of the ?Type syntax rather than the Type|null
> syntax.
>  * Only supports "false" as a pseudo-type, not "true".
>  * Slightly simplified semantics for the coercive typing mode.
>
> Regards,
> Nikita
>

An implementation of this proposal is now available at
https://github.com/php/php-src/pull/4838. As the implementation didn't turn
up any new issues, I think it's time to move this RFC forward to voting.

Nikita


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Dmitry Stogov]

Hi Nikita,

Can you please give me one/two days, before starting the voting, for 
implementation review (at least until October 25),

Thanks. Dmitry.


From: Nikita Popov 
Sent: Tuesday, October 22, 2019 12:36
To: PHP internals 
Subject: [PHP-DEV] Re: [RFC] Union Types v2

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>
> Relatively to the previous proposal by Bob (
> https://wiki.php.net/rfc/union_types), I think the main differences in
> this proposal are:
>  * Updated to specify interaction with new language features, like full
> variance and property types.
>  * Updated for the use of the ?Type syntax rather than the Type|null
> syntax.
>  * Only supports "false" as a pseudo-type, not "true".
>  * Slightly simplified semantics for the coercive typing mode.
>
> Regards,
> Nikita
>

An implementation of this proposal is now available at
https://github.com/php/php-src/pull/4838. As the implementation didn't turn
up any new issues, I think it's time to move this RFC forward to voting.

Nikita


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.

Re: [PHP-DEV] Reverting "Link executable files using non PIC object files"

[Dmitry Stogov]

reverted

From: Derick Rethans 
Sent: Thursday, October 10, 2019 13:11
To: Dmitry Stogov 
Cc: Peter Kokot ; Nikita Popov ; 'Remi Collet' 
; PHP internals 
Subject: Re: [PHP-DEV] Reverting "Link executable files using non PIC object 
files"

CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.

Hi Dmitry,

On Mon, 7 Oct 2019, Dmitry Stogov wrote:

> There were a number of build problems caused by my PR
> https://github.com/php/php-src/pull/4678<https://github.com/php/php-src/pull/4678#issuecomment-532204164>
>
> Today I got another report from Remi
> https://github.com/php/php-src/commit/f633c347574c0d814050b4bf2493e0cac6a5988c
> Although, the patch makes visible performance improvement, it's
> probably better to revert it and all the related fixes for PHP-7.4.

I think we should revert it (and the related) for PHP 7.4 indeed. We
have plenty of time for PHP 8 to see if we can properly address it
there. And now is not the time to be experimental with the
soon-to-be-released PHP 7.4.0.

cheers,
Derick

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Become my Patron: https://www.patreon.com/derickr
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

[PHP-DEV] Reverting "Link executable files using non PIC object files"

[Dmitry Stogov]

Hi,

There were a number of build problems caused by my PR 
https://github.com/php/php-src/pull/4678

Today I got another report from Remi 
https://github.com/php/php-src/commit/f633c347574c0d814050b4bf2493e0cac6a5988c
Although, the patch makes visible performance improvement, it's probably better 
to revert it and all the related fixes for PHP-7.4.

Thanks. Dmitry.

[PHP-DEV] Re: Constant propagation inside same compilation unit

[Dmitry Stogov]

On 9/18/19 7:18 PM, Nikita Popov wrote:
> On Wed, Sep 18, 2019 at 5:10 PM Benjamin Coutu  > wrote:
> 
> Hello,
> 
> During performance testing of the (awesome) PHP 7.4 preloading
> feature I stumbled upon a lost opportunity I'd like to point out
> (though this has nothing to do with preloading per se).
> 
> Please consider the following snippet:
> 
> const TEST = 14;
> 
> function d() {
>    echo TEST;
> }
> 
> The function "d" yields the following opcodes:
> 
> #0 FETCH_CONSTANT "TEST" ~0
> #1 ECHO ~0
> #2 RETURN<-1> null
> 
> meaning, that the constant "TEST" does not propagate into the
> function, though both, the constant and the function, are defined in
> the same file.
> 
> Same goes for this kind of snippet:
> 
> class D {
>          const C = TEST;
> 
>          public function d() {
>                  echo self::C;
>          }
> }
> 
> Here the method "d" yields the following opcodes:
> 
> #0 FETCH_CLASS_CONSTANT "C" ~0
> #1 ECHO ~0
> #2 RETURN<-1> null
> 
> Interestingly enough, class constants propagate as one would expect:
> 
> class D {
>          const C = 14;
> 
>          public function d() {
>                  echo self::C;
>          }
> }
> 
> #0 ECHO 14
> #1 RETURN<-1> null
> 
> I don't see why constants defined in the same file couldn't
> propagate throughout the same compilation unit during compile time,
> as they can never have a different value (locally in that particular
> defining file) at runtime.
> Is this just an oversight or is there some deeper reasoning behind
> this that I'm simply missing?
> 
> In terms of preloading this would be particularly beneficial, cause
> one cloud then include/require files that define global constants
> before compiling files that contain those constants, thereby
> propagating their values throughout the code base during preloading.
> That would eliminate a lot of the runtime cost of (not so truly
> constant) constants.
> 
> Please let me know your thoughts.
> 
> 
> This optimization is unsafe, because the constant may already be 
> previously defined, in which case the "const" will be ignored with a 
> notice. There is an optimization flag that enables it, try 
> opcache.optimization_level=-1.
> 
> Unfortunately I just noticed that I missed this notice during "engine 
> warning reclassification" RFC, because it occurs in zend_constants. 
> Otherwise we might have changed it to an exception. (Though given recent 
> discussions, probably not.)
> 
> Nikita

I proposed this 3 years ago (for PHP-7.1), but then delayed for PHP-8.

https://wiki.php.net/rfc/constant_redefinition

Thanks. Dmitry.

[PHP-DEV] Re: commit 374f76998 causes getenv to be define with Xdebug loaded

[Dmitry Stogov]

I'll try to check what was wrong with this commit and xdebug.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Wednesday, June 12, 2019 9:38:54 PM
To: Derick Rethans
Cc: Dmitry Stogov; PHP Developers Mailing List
Subject: Re: commit 374f76998 causes getenv to be define with Xdebug loaded

Hi all,

My clumsy ass reverted that in PHP-7.4, totally and utterly by accident, and 
since it resolved Dericks problem, I went ahead and reverted in master also 
rather than make maybe unnecessary noise.

Very very sorry about that, I totally intended to get Dmitry's approval/opinion.

Terrible form, I'm sorry, I just pushed in the wrong shell.

If the revert is terrible, feel free to shout at me and revert the revert.

Cheers
Joe

On Wed, 12 Jun 2019 at 20:04, Derick Rethans 
mailto:der...@php.net>> wrote:
Hi Dmitry,

I've just fetch the latest PHP-7.4 source from GIT to finalise Xdebug
support for it, and after compiling PHP and Xdebug, I now run into the
following error:

Warning: define() expects at least 2 parameters, 1 given in
/home/derick/dev/php/derickr-xdebug/run-xdebug-tests.php on line 2749

Line 2749 is not using define, and instead is:
$JUNIT = getenv('TEST_PHP_JUNIT');

I have tracked this down with git bisect to be this commit:
https://github.com/php/php-src/commit/374f76998

Could you have a look and let me know what's up? Joe suggests that this
might need reverting.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Dmitry Stogov]

Hi Arvids,


It's possible to test JIT with PHP-7.4 building PHP from 
https://github.com/zendtech/php-src/tree/jit-dynasm-7.4

But this branch is not going to be supported anymore.


Thanks. Dmitry.


From: Arvids Godjuks 
Sent: Friday, March 29, 2019 5:17:41 PM
To: Joe Watkins
Cc: Dmitry Stogov; release-manag...@php.net; PHP internals
Subject: Re: [PHP-DEV] Re: PHP 8 Preview Releases

Hello,

I'd like to add that as the userland developer, it would be nice to be able to 
build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8 brings 
enough changes, it would not be realistic to fix our apps to be compatible with 
PHP 8 months or years away from actual release.

пт, 29 мар. 2019 г. в 15:58, Joe Watkins 
mailto:krak...@gmail.com>>:
Hi Dmitry,

I'm not suggesting we do it right now, I'm suggesting we look at the
planning of it right now as it deviates from our normal release cycle.

At the moment we should just consider how we want it to work, including
when it should start ...

Cheers
Joe

On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov 
mailto:dmi...@zend.com>> wrote:

> Hi Joe,
>
>
> I think, PHP-8 preview is too early.
>
> We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> features (may be I forgot something) only deprecations and some internal
> improvements
>
> .
>
> According to JIT, it's probably going to be changed a lot in the nearest
> future.
>
>
> Thanks. Dmitry.
> --
> *From:* Joe Watkins mailto:krak...@php.net>>
> *Sent:* Friday, March 29, 2019 3:40:04 PM
> *To:* release-manag...@php.net<mailto:release-manag...@php.net>; PHP 
> internals; Dmitry Stogov
> *Subject:* PHP 8 Preview Releases
>
> Morning internals,
>
> Since we now have a result for JIT and we know it will be included in PHP
> 8, I think it's time to visit the idea brought up in discussion to have
> preview releases of PHP 8.
>
> I'm interested in hearing what kind of schedules we think are going to be
> useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
> bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
> or too fast.
>
> Thoughts please (especially from Dmitry) ?
>
> Cheers
> Joe
>
>
>


--
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com<mailto:arvids.godj...@gmail.com>
Skype: psihius
Telegram: @psihius https://t.me/psihius

[PHP-DEV] Re: PHP 8 Preview Releases

[Dmitry Stogov]

Hi Joe,


I think, PHP-8 preview is too early.

We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major features 
(may be I forgot something) only deprecations and some internal improvements

.

According to JIT, it's probably going to be changed a lot in the nearest future.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Friday, March 29, 2019 3:40:04 PM
To: release-manag...@php.net; PHP internals; Dmitry Stogov
Subject: PHP 8 Preview Releases

Morning internals,

Since we now have a result for JIT and we know it will be included in PHP 8, I 
think it's time to visit the idea brought up in discussion to have preview 
releases of PHP 8.

I'm interested in hearing what kind of schedules we think are going to be 
useful - it's tempting to say let's track PHP-7.4 releases, possibly with a 
bi-monthly interval, but I'm not sure if that may be too soon, or too slow, or 
too fast.

Thoughts please (especially from Dmitry) ?

Cheers
Joe

[PHP-DEV] [RFC] [VOTE] [Result] JIT

[Dmitry Stogov]

Hi @internals,


The JIT RFC https://wiki.php.net/rfc/jit is accepted to be merged into PHP-8 
only.

I'm going to perform the actual merge on Monday morning and then start working 
on deeper integration of JIT with VM.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [VOTE] JIT

[Dmitry Stogov]

On 3/21/19 4:27 PM, Joe Watkins wrote:
> Afternoon Dmitry,
> 
>  > If you liked to change this, you might do it together with 50%+1 -> 
> 2/3 majority change.
> 
> The super majority RFC was already accepted ...
> 
>  > If you agree, I can extend voting period "pseudo proportionally" (to 
> be 1.5 week), but I don't like to lose the following week.
> 
> I'm not sure what you loose, I'm sure that you gain the possibility of 
> more voters having the opportunity to vote.

I'm talking about a week of work, that I'm going to start when JIT accepted.

Thanks. Dmitry.

> 
> Cheers
> Joe
> 
> On Thu, 21 Mar 2019 at 14:11, Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> Hey Joe,
> 
> 
> Voting rules nothing say about "complex features" and 2 weeks voting
> period.
> 
> If you liked to change this, you might do it together with 50%+1 ->
> 2/3 majority change.
> 
> 
> If you agree, I can extend voting period "pseudo proportionally" (to
> be 1.5 week), but I don't like to lose the following week.
> 
> 
> Thanks. Dmitry.
> 
> 
> --------
> *From:* Joe Watkins mailto:krak...@gmail.com>>
> *Sent:* Thursday, March 21, 2019 3:12:31 PM
> *To:* Dmitry Stogov
> *Cc:* PHP internals
> *Subject:* Re: [PHP-DEV] [RFC] [VOTE] JIT
> Such complex and far reaching features should clearly have a two
> week voting period, please update the RFC.
> 
> Cheers
> Joe
> 
> On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> Hey,
> 
> I'm starting the vote on JIT RFC.
> 
> 
> 
> https://wiki.php.net/rfc/jit<https://wiki.php.net/rfc/typed_properties_v2>
> 
> 
> The voting period is one week, until Thursday 28-03-2019 GMT.
> 
> 
> Since the initial announcement and following discussions, RFC
> was imprved and implementation extended with support for Clang,
> Windows and ZTS builds.
> Please reread RFC carefully.
> 
> 
> Thanks. Dmitry.
> 

Re: [PHP-DEV] [RFC] [VOTE] JIT

[Dmitry Stogov]

Hey Joe,


Voting rules nothing say about "complex features" and 2 weeks voting period.

If you liked to change this, you might do it together with 50%+1 -> 2/3 
majority change.


If you agree, I can extend voting period "pseudo proportionally" (to be 1.5 
week), but I don't like to lose the following week.


Thanks. Dmitry.



From: Joe Watkins 
Sent: Thursday, March 21, 2019 3:12:31 PM
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] JIT

Such complex and far reaching features should clearly have a two week voting 
period, please update the RFC.

Cheers
Joe

On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov 
mailto:dmi...@zend.com>> wrote:
Hey,

I'm starting the vote on JIT RFC.


 https://wiki.php.net/rfc/jit<https://wiki.php.net/rfc/typed_properties_v2>


The voting period is one week, until Thursday 28-03-2019 GMT.


Since the initial announcement and following discussions, RFC was imprved and 
implementation extended with support for Clang, Windows and ZTS builds.
Please reread RFC carefully.


Thanks. Dmitry.

[PHP-DEV] [RFC] [VOTE] JIT

[Dmitry Stogov]

Hey,

I'm starting the vote on JIT RFC.


 https://wiki.php.net/rfc/jit


The voting period is one week, until Thursday 28-03-2019 GMT.


Since the initial announcement and following discussions, RFC was imprved and 
implementation extended with support for Clang, Windows and ZTS builds.
Please reread RFC carefully.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi Internals,

https://wiki.php.net/rfc/jit

Now JIT also supports ZTS (checked on Linux and Windows).
Please, test and report problems.

So, complains about JIT compatibility matrix are satisfied.
It should be some incompatibilities with ZTS on Mac, but this easily 
fixable.

I'll spend some additional time on code cleanup, and then start voting.

Ideas for RFC and code improvement are welcome.

Thanks. Dmitry.



On 1/31/19 12:43 PM, Dmitry Stogov wrote:
> Hi Internals,
> 
> 
> I'm glad to finally propose including JIT into PHP.
> 
> 
> https://wiki.php.net/rfc/jit
> 
> 
> In the current state it may be included both into PHP-8, where we are going 
> to continue active improvement, and into PHP-7.4, as an experimental feature.
> 
> 
> Thanks. Dmitry.
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

JIT also works for non-ZTS PHP Windows builds now.


Thanks. Dmitry.


From: Anatol Belski  on behalf of Anatol Belski 

Sent: Friday, March 1, 2019 3:47:07 PM
To: Dmitry Stogov; Joe Watkins
Cc: PHP internals
Subject: RE: [PHP-DEV] [RFC] JIT

Hi,

> -Original Message-
> From: Dmitry Stogov 
> Sent: Friday, February 22, 2019 1:49 PM
> To: Joe Watkins 
> Cc: PHP internals ; Anatol Belski 
> Subject: Re: [PHP-DEV] [RFC] JIT
>
> Thanks to Anatol, who started working on Windows build and "enforced" me
> to implement MSVC support :)
>
Owing to Dmitry's great work on this, the Windows part is now in a very good 
shape. Zend/bench.php shows at least 4x better performance with Opcache+JIT vs. 
just Opcache on current master. A dev snapshot x64/NTS of the today's 
jit-dynasm branch are available here

https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190301/

Regards

Anatol

> On 2/22/19 3:21 PM, Joe Watkins wrote:
> > Thanks for all the effort Dmitry, it's looking in much better shape.
> >
> > Cheers
> > Joe
> >
> > On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov  > <mailto:dmi...@zend.com>> wrote:
> >
> > Hi Internals,
> >
> >
> > The RFC and implementation was updated once again.
> >
> >
> > https://wiki.php.net/rfc/jit
> >
> >
> > Now JIT supports PHP builds with compilers without GCC explicit
> > global register variables extension.
> >
> > This means we support CLANG/LLVM (Tested on Linux. Should work on
> > Mac as well) and MSVC.
> >
> > Complete Windows support is not implemented yet, but I don't see any
> > big problems anymore.
> >
> >
> > ZTS support might be implemented after implementation of proposed
> > TSRM API improvement.
> >
> >
> > Thanks. Dmitry.
> >
> >
> > 
> > From: Dmitry Stogov mailto:dmi...@zend.com>>
> > Sent: Wednesday, February 13, 2019 16:07
> > To: PHP internals
> > Subject: Re: [PHP-DEV] [RFC] JIT
> >
> > Hi Internals,
> >
> > According to comments, code reviews and discussions, JIT RFC was
> > extended with few new sections.
> >
> > Please, consider to review the RFC once again.
> >
> > https://wiki.php.net/rfc/jit
> >
> > Any suggestion for RFC improvement are welcome.
> >
> > I'm not going to invest significant time into JIT implementation
> > improvement itself, at this point. So, ideas are also welcome, but don't
> > expect to get them implemented tomorrow.
> >
> > Thanks. Dmitry.
> >
> > On 1/31/19 12:43 PM, Dmitry Stogov wrote:
> >  > Hi Internals,
> >  >
> >  >
> >  > I'm glad to finally propose including JIT into PHP.
> >  >
> >  >
> >  > https://wiki.php.net/rfc/jit
> >  >
> >  >
> >  > In the current state it may be included both into PHP-8, where we are
> >  > going to continue active improvement, and into PHP-7.4, as an
> >  > experimental feature.
> >  >
> >  >
> >  > Thanks. Dmitry.
> >  >
> >

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Dmitry Stogov]

Hi Nikita,


Yeah, this is a big BC break, but I think, it's a good time to make some 
"cleanup" in PHP-8.

The only thing, I don't like is a difference between leading and trailing 
spaces.

They should behave in the same way.


Thanks. Dmitry.


From: Nikita Popov 
Sent: Tuesday, February 26, 2019 3:27:23 PM
To: PHP internals
Subject: [PHP-DEV] [RFC] Saner string to number comparisons

Hi internals,

I think it is well known that == in PHP is a pretty big footgun. It doesn't
have to be. I think that type juggling comparisons in a language like PHP
have some merit, it's just that the particular semantics of == in PHP make
it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
returns true.

I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
and other non-strict comparisons, when used between a number and a string:

https://wiki.php.net/rfc/string_to_number_comparison

The tl;dr is that if you compare a number and a numeric string, they'll be
compared as numbers. Otherwise, the number is converted into a string and
they'll be compared as strings.

This is a very significant change -- not so much because the actual BC
breakage is expected to be particularly large, but because it is a silent
change in core language semantics, which makes it hard to determine whether
or not code is affected by the change. There are things we can do about
this, for example the RFC suggests that we might want to have a transition
mode where we perform the comparison using both the old and the new
semantics and warn if the result differs.

I think we should give serious consideration to making such a change. I'd
be interested to hear whether other people think this is worthwhile, and
how we could go about doing it, while minimizing breakage.

Regards,
Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Thanks to Anatol, who started working on Windows build and "enforced" me 
to implement MSVC support :)

On 2/22/19 3:21 PM, Joe Watkins wrote:
> Thanks for all the effort Dmitry, it's looking in much better shape.
> 
> Cheers
> Joe
> 
> On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> Hi Internals,
> 
> 
> The RFC and implementation was updated once again.
> 
> 
> https://wiki.php.net/rfc/jit
> 
> 
> Now JIT supports PHP builds with compilers without GCC explicit
> global register variables extension.
> 
> This means we support CLANG/LLVM (Tested on Linux. Should work on
> Mac as well) and MSVC.
> 
> Complete Windows support is not implemented yet, but I don't see any
> big problems anymore.
> 
> 
> ZTS support might be implemented after implementation of proposed
> TSRM API improvement.
> 
> 
> Thanks. Dmitry.
> 
> 
> 
> From: Dmitry Stogov mailto:dmi...@zend.com>>
> Sent: Wednesday, February 13, 2019 16:07
> To: PHP internals
> Subject: Re: [PHP-DEV] [RFC] JIT
> 
> Hi Internals,
> 
> According to comments, code reviews and discussions, JIT RFC was
> extended with few new sections.
> 
> Please, consider to review the RFC once again.
> 
> https://wiki.php.net/rfc/jit
> 
> Any suggestion for RFC improvement are welcome.
> 
> I'm not going to invest significant time into JIT implementation
> improvement itself, at this point. So, ideas are also welcome, but don't
> expect to get them implemented tomorrow.
> 
> Thanks. Dmitry.
> 
> On 1/31/19 12:43 PM, Dmitry Stogov wrote:
>  > Hi Internals,
>  >
>  >
>  > I'm glad to finally propose including JIT into PHP.
>  >
>  >
>  > https://wiki.php.net/rfc/jit
>  >
>  >
>  > In the current state it may be included both into PHP-8, where we are
>  > going to continue active improvement, and into PHP-7.4, as an
>  > experimental feature.
>  >
>  >
>  > Thanks. Dmitry.
>  >
> 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi Internals,


The RFC and implementation was updated once again.


https://wiki.php.net/rfc/jit


Now JIT supports PHP builds with compilers without GCC explicit global register 
variables extension.

This means we support CLANG/LLVM (Tested on Linux. Should work on Mac as well) 
and MSVC.

Complete Windows support is not implemented yet, but I don't see any big 
problems anymore.


ZTS support might be implemented after implementation of proposed TSRM API 
improvement.


Thanks. Dmitry.



From: Dmitry Stogov 
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.

On 1/31/19 12:43 PM, Dmitry Stogov wrote:
> Hi Internals,
>
>
> I'm glad to finally propose including JIT into PHP.
>
>
> https://wiki.php.net/rfc/jit
>
>
> In the current state it may be included both into PHP-8, where we are
> going to continue active improvement, and into PHP-7.4, as an
> experimental feature.
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

> 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  <mailto:dmi...@zend.com>> wrote:
> 
> Hi,
> 
> On 2/14/19 5:22 PM, Joe Watkins wrote:
>  > Morning all,
>  >
>  > This idea of an experimental feature as complex as a JIT is
> dangerous. It
>  > is not finished, and dmitry has said he's not willing to put more
> time into
>  > until it's merged. That's his prerogative, and it is ours to say
> that we
>  > don't want unfinished software that only one or two people really
>  > understand in PHP. All of the rest of internals need all of the time
>  > between now and PHP 8 to educate ourselves on this so that we
> function as
>  > well as we do now when it comes to finding and fixing bugs, and
> pushing PHP
>  > forward.
> 
> Few years ago I was claimed for development PHPNNG privately, but that
> time we delivered to @internals almost completed solution. Now you
> don't
> like the solution, because it's incomplete in your opinion (ZTS
> support,
> etc), and the development makes troubles...
> 
> 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.
> 
> 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...
> However, I keep it in sync with master and PHP-7.4, fix reported
> problems, respond to code review comments, etc (just check git commits
> history).
> 
> In last email I asked for ideas for RFC improvement (like notes about
> unsupported ZTS). May be it makes sense to add cons/pros for additional
> PHP-7.4 proposal. May be write something more clear (I'm not a native
> speaker).
> 
> But this "a bit toxic" discussion, at least, steals time from
> constructive things.
> 
> Joe, please, don't take anything personally.
> Despite I wrote above, I appreciate your involvement in PHP development
> and respect your opinion regarding JIT, ZTS. etc.
> 
> Thanks. Dmitry.
> 
> 
>  > Merging the JIT into 7.4 puts a brick wall in the way of progress
>  > that none of us have the tools to climb over.
>  >
>  > I hear the argument about wanting to test, but anyone with sufficient
>  > expertise to test the JIT is capable of building the branch
> available on
>  > github, we do not need to push out an incomplete product to the
> entire
>  > world for the sake of that handful of individuals who will
> actually test.
>  >
>  > I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
>  > current form, and would ask everyone to please think very
> carefully about
>  > it, prior to supporting it.
>  >
>  > Thanks
>  > Joe
>  >
>  >
>  > On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks
> mailto:arvids.godj...@gmail.com>>
>  > wrote:
>  

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi,

On 2/14/19 5:22 PM, Joe Watkins wrote:
> Morning all,
> 
> This idea of an experimental feature as complex as a JIT is dangerous. It
> is not finished, and dmitry has said he's not willing to put more time into
> until it's merged. That's his prerogative, and it is ours to say that we
> don't want unfinished software that only one or two people really
> understand in PHP. All of the rest of internals need all of the time
> between now and PHP 8 to educate ourselves on this so that we function as
> well as we do now when it comes to finding and fixing bugs, and pushing PHP
> forward.

Few years ago I was claimed for development PHPNNG privately, but that 
time we delivered to @internals almost completed solution. Now you don't 
like the solution, because it's incomplete in your opinion (ZTS support, 
etc), and the development makes troubles...

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.

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...
However, I keep it in sync with master and PHP-7.4, fix reported 
problems, respond to code review comments, etc (just check git commits 
history).

In last email I asked for ideas for RFC improvement (like notes about 
unsupported ZTS). May be it makes sense to add cons/pros for additional 
PHP-7.4 proposal. May be write something more clear (I'm not a native 
speaker).

But this "a bit toxic" discussion, at least, steals time from 
constructive things.

Joe, please, don't take anything personally.
Despite I wrote above, I appreciate your involvement in PHP development 
and respect your opinion regarding JIT, ZTS. etc.

Thanks. Dmitry.


> Merging the JIT into 7.4 puts a brick wall in the way of progress
> that none of us have the tools to climb over.
> 
> I hear the argument about wanting to test, but anyone with sufficient
> expertise to test the JIT is capable of building the branch available on
> github, we do not need to push out an incomplete product to the entire
> world for the sake of that handful of individuals who will actually test.
> 
> I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
> current form, and would ask everyone to please think very carefully about
> it, prior to supporting it.
> 
> Thanks
> Joe
> 
> 
> On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks 
> wrote:
> 
>> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas >> :
>>
 [...] I think that whether or not we include it in 7.4
 is a tactical decision (and I'm not sure myself where I stand on it),
>>> but I
 do think there's a reasonable case for both directions.

>>>
>>> If I may add some voice to Zeev's arguments, being able to play with JIT
>> as
>>> early as possible would allow the community to experiment using PHP in
>>> areas where it doesn't fit right now. Having to wait 2 more years to
>>> discover that maybe it's useful to build some new libraries could be a
>>> waste of time at the tactical level (there are other technologies around
>>> that move fast also :) )
>>>
>>> Not to detract from the technical challenges of moving in this direction,
>>> of course.
>>> Just my 2cts from a "userland" guy :)
>>>
>>> Nicolas
>>>
>>
>> Hello everyone,
>>
>> I agree with this sentiment and the general idea of shipping JIT as
>> experimental in 7.4 and required to build with a configure flag.
>> master for 8.0 is going to contain much more and be more unstable and not
>> practical for testing what JIT can do at that point due to all other
>> features and improvements going into it like additional optimizations and
>> platform support.
>> It will give me, as a userland developer, a platform where I can actually
>> play with it early and on a stable platform. And I understand what I'm
>> doing at that point.
>>
>> --
>> Arvīds Godjuks
>>
>> +371 26 851 664
>> arvids.godj...@gmail.com
>> Skype: psihius
>> Telegram: @psihius https://t.me/psihius
>>
> 

[PHP-DEV] Re: ZTS improvement idea

[Dmitry Stogov]

On 2/14/19 8:55 PM, Anatol Belski wrote:
> Hi Nikita,
> 
>> -Original Message-
>> From: Nikita Popov 
>> Sent: Wednesday, February 13, 2019 1:02 AM
>> To: Dmitry Stogov 
>> Cc: Joe Watkins ; Bob Weinand ;
>> Nikita Popov ; Anatol Belski (a...@php.net) ;
>> z...@php.net; PHP internals 
>> Subject: Re: ZTS improvement idea
>>
>> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov > <mailto:dmi...@zend.com> > wrote:
>>
>>
>>  Hi,
>>
>>
>>
>>
>>  After JIT+ZTS related discussion with Joe and Bob, and some related
>> analyzes.
>>
>>  I came to more or less formed design idea and described it at
>> https://wiki.php.net/zts-improvement
>>
>>  This is not an RFC and I'm not sure, if I like to implement TSRM
>> changes myself now.
>>
>>
>>
>>
>>  Comments are welcome.
>>
>>
>> Hi Dmitry,
>>
>> Thanks for looking into this issue. As a possible alternative I would like to
>> suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on
>> Linux (on Windows this is not possible due to DLL linkage restrictions).
>> __thread generates very good code (single load over %fs segment with
>> constant address) if the global is defined and used in an executable. I'm not
>> sure what kind of code it generates when TLS is declared in an executable
>> and used in a shared object, but as direct access from extensions to the
>> engine globals shouldn't be common, it's probably okay even if it uses
>> __tls_get_addr.
>>
> TLS data available across shared objects is a GNU extension and AFAIK there's 
> a lot of black magic behind it. Thread local storage should be indeed local 
> to some scope, be it a function or a binary unit, as per design. Like for 
> C++11 as well, it's thread_local we currently use. It'd hurt the portability 
> and likely introduce issues in the future, as it might affect any non GNU 
> systems which we rarely test. Otherwise, of course it would be easy to say, 
> we add ZEND_TLS to the definition, and be good :)

In two words, if we make executor_glabal to be "__thread", we will get 
troubles accessing it from DSO extensions. Right?

Thanks. Dmitry.

> 
> Thanks
> 
> Anatol
> 

[PHP-DEV] Re: ZTS improvement idea

[Dmitry Stogov]

Hi Anatol,

On 2/14/19 8:44 PM, Anatol Belski wrote:
> Hi Dmitry,
> 
>> -Original Message-----
>> From: Dmitry Stogov 
>> Sent: Wednesday, February 13, 2019 12:26 AM
>> To: Joe Watkins ; Bob Weinand ;
>> Nikita Popov ; Anatol Belski (a...@php.net) ;
>> z...@php.net
>> Cc: PHP internals 
>> Subject: ZTS improvement idea
>>
>> Hi,
>>
>>
>>
>>
>> After JIT+ZTS related discussion with Joe and Bob, and some related
>> analyzes.
>>
>> I came to more or less formed design idea and described it at
>> https://wiki.php.net/zts-improvement
>>
> I thought about it as well. The reason for the additional dereference > 
> levels is probably ,that every globals structure has its own size.
> That way, it needs to go on the heap.

Not necessary. In case all the structures are known at MINIT time, we 
may realloc()-ate the whole flattened tsrm_tls_entry and then access 
data faster.

It may be a problem with dl(), but it must already be problematic in ZTS 
build.

> What we indeed could do were handling some specific known structures
> a different way. It'd be like EG and others, that belong to the very
> core and are always available. Other globals, especially from extensions
> that can be built shared, would be probably still handled the old way.
> Maybe it would be a good start to speedup the very core as first. I'd
> wonder which particular data structures and mechanism you had in mind.

In https://wiki.php.net/zts-improvement I proposed:

  - make "executor_globals_id" to be constant (it's quite easy to do).
  - make all "...globals_id" to keep offsets instead if indexes (this is 
a bit more complex and require changes in TSRM implementation).


Thanks. Dmitry.

> 
>   
>> This is not an RFC and I'm not sure, if I like to implement TSRM changes
>> myself now.
>>
> Certainly not an RFC. I'm short of time as well, perhaps it will change in a 
> couple of months.
> 
> Thanks
> 
> Anatol
> 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/14/19 2:38 PM, Zeev Suraski wrote:
> On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov  wrote:
>> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski  wrote:
>>> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann 

>>   * 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.
>>
> 
> That's a valid point, but given we're only a few months away from
> feature-completing 7.4, as well as the general direction that most probably
> more substantial changes will make it into 8.0 - I don't know that the
> initial investment in a 7.4 version of JIT (and the marginal cost of then
> maintaining it) would be too big.  I believe Dmitry's proposing that while
> realizing the bulk of the work will fall on his shoulders if we decide to
> do it.

Currently, I'm keeping in consistency two JIT branches. For master and 
PHP-7.4 (links in RFC). In case 7.4 don't pass, I stop its support.

>> * 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.
>>
> 
> We both agree that if we include JIT in 7.4 it will dilute from the 'shiny
> new thing' aspect of it when it's available in 8.0.  That said -
> realistically, it seems that JIT will not be as revolutionary as phpng was
> in terms of real world performance impact, so if I had to guess - migration
> to 8 it would be a lot slower than the migration to 7 (the motivation to
> upgrade to 7 in the vast majority of companies I came across was
> predominantly around performance;  new features were a nice bonus).

Marketing is simple :) We like to make good JIT in PHP-8, and we need 
feedback to really do it. The more interest we get to JIT in PHP-7.4 the 
better JIT might be implemented in PHP-8.

> * 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).

Again, the early we know problems, the better.
Most people will start testing PHP-8 with their third-party extension 
only after release. Then we will start getting reports about problems, 
and the solutions might need serious API or design changes, that are not 
allowed in minor releases...

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/14/19 3:02 AM, Eugene Leonovich wrote:
> On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan  <mailto:weir...@gmail.com>> wrote:
> 
> On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
>  > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
>  > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s
> (95.1%)
>  > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
>  > > -dopcache.jit=1201): 29.95s (92.7%)
>  >
>  > It may be interesting to try -dopcache.jit=1235. It should JIT
> only hot
>  > functions and requires some warm-up.
> 
> For this use case 1201 was the fastest of all the options I tried
> (including 1235).
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> Here are my results of benchmarking rybakit/msgpack.php:
> 
> bench.php, w/o jit:
>      Total 9.8220 4.3121
> 
> bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
>      Total 8.7255 3.3350
> 
> bench2.php, w/o jit:
>      pure msgpack: 2.2818 sec
>      pure msgpack packed: 2.1717 sec
> 
> bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
>      pure msgpack: 1.5221 sec
>      pure msgpack packed: 1.4739 sec
> 
> Details: https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f

1.3-1.5 times speed-up.
Thanks for benchmarking.

Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was 
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation 
improvement itself, at this point. So, ideas are also welcome, but don't 
expect to get them implemented tomorrow.

Thanks. Dmitry.

On 1/31/19 12:43 PM, Dmitry Stogov wrote:
> Hi Internals,
> 
> 
> I'm glad to finally propose including JIT into PHP.
> 
> 
> https://wiki.php.net/rfc/jit
> 
> 
> In the current state it may be included both into PHP-8, where we are 
> going to continue active improvement, and into PHP-7.4, as an 
> experimental feature.
> 
> 
> Thanks. Dmitry.
> 

[PHP-DEV] Re: ZTS improvement idea

[Dmitry Stogov]

Hi Joe,

On 2/13/19 12:26 PM, Joe Watkins wrote:
> Morning all,
> 
> I'm very pleased to see effort going into this, and the resulting ideas.
> 
> I don't have anything to add about the implementation.
> 
> Since most people are not interested in ZTS, there aren't going to be 
> many voices pushing you to actually make changes, so I want to be that 
> voice.
> 
> The ZTS build is very commonly used in Windows today, and I'm sure 
> everyone doing that would appreciate you making these changes as soon as 
> reasonable, which looks like 7.4, beyond that before we can talk about 
> developing JIT support in Windows, ZTS support must be in place.

There are many things that would be great to get, but with very limited 
forces, we have to set priorities and select the most desired 
functionality, to work on it first.

Thanks. Dmitry.



> 
> Thanks for the effort so far.
> 
> Cheers
> Joe
> 
> On Wed, 13 Feb 2019 at 10:02, Nikita Popov  <mailto:nikita@gmail.com>> wrote:
> 
> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> Hi,
> 
> 
> After JIT+ZTS related discussion with Joe and Bob, and some
> related analyzes.
> 
> I came to more or less formed design idea and described it at
> https://wiki.php.net/zts-improvement
> 
> This is not an RFC and I'm not sure, if I like to implement TSRM
> changes myself now.
> 
> 
> Comments are welcome.
> 
> 
> Hi Dmitry,
> 
> Thanks for looking into this issue. As a possible alternative I
> would like to suggest the use of ZEND_TLS (__thread) for the
> EG/CG/BG etc globals on Linux (on Windows this is not possible due
> to DLL linkage restrictions). __thread generates very good code
> (single load over %fs segment with constant address) if the global
> is defined and used in an executable. I'm not sure what kind of code
> it generates when TLS is declared in an executable and used in a
> shared object, but as direct access from extensions to the engine
> globals shouldn't be common, it's probably okay even if it uses
> __tls_get_addr.
> 
> Nikita
> 

[PHP-DEV] Re: ZTS improvement idea

[Dmitry Stogov]

Hi Nikita,


On 2/13/19 12:02 PM, Nikita Popov wrote:
> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> Hi,
> 
> 
> After JIT+ZTS related discussion with Joe and Bob, and some related
> analyzes.
> 
> I came to more or less formed design idea and described it at
> https://wiki.php.net/zts-improvement
> 
> This is not an RFC and I'm not sure, if I like to implement TSRM
> changes myself now.
> 
> 
> Comments are welcome.
> 
> 
> Hi Dmitry,
> 
> Thanks for looking into this issue. As a possible alternative I would 
> like to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc 
> globals on Linux (on Windows this is not possible due to DLL linkage 
> restrictions).

I played with __thread long time ago (may be 10 years), and that time it 
didn't work as expected. I can't remember the exact problems. May be it 
made troubles when used in DSO PHP build with DSO extensions, may be the 
size of "__thread" segment was limited, may be both.

> __thread generates very good code (single load over %fs 
> segment with constant address) if the global is defined and used in an 
> executable.

I suppose 2 loads:

movqexecutor_globals@gottpoff(%rip), %rax
movq%fs:field_offset(%rax), %rax

> I'm not sure what kind of code it generates when TLS is 
> declared in an executable and used in a shared object, but as direct 
> access from extensions to the engine globals shouldn't be common, it's 
> probably okay even if it uses __tls_get_addr.

The main problem with "__thread" might be portability.
I especially thought about keeping TSRM layer with the same API, to 
avoid portability issues, but if "__thread" works fine, we definitely 
should use it.

On the other hand, I'm not sure, who uses ZTS build today and if they 
need performance.

Thanks. Dmitry.


> 
> Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ZTS improvement idea

[Dmitry Stogov]

Hi,


After JIT+ZTS related discussion with Joe and Bob, and some related analyzes.

I came to more or less formed design idea and described it at 
https://wiki.php.net/zts-improvement

This is not an RFC and I'm not sure, if I like to implement TSRM changes myself 
now.


Comments are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

On 2/6/19 8:28 PM, Joe Watkins wrote:
> Afternoon Dmitry, Nikita,
> 
> I've cleaned that up to read "changes to PHP" rather than talking about 
> merges, apologies for the confusion, just used the wrong words.
> 
> To re-iterate what Nikita said, this is not about changing what requires 
> an RFC, and not about forcing every change to require an RFC; We're all 
> very aware that there is an almost constant stream of minor improvements 
> committed by core maintainers that don't require RFC, and this RFC does 
> not seek to stand in your way.

The "Normative text" section looks clear now.
I would remove all the rest of the "Proposal" section, assuming that 
it's reflected in the "Normative text", anyway.

Additional note (unrelated to this RFC, but related to RFC process).
It would be great to define some formal procedure of approval of RFC 
implementation patches.
- When a patch is required and good enough, to turn RFC into voting?
- When a patch of accepted RFC may (or may not) be merged?

Currently, this procedure is completely informal.

Thanks. Dmitry.




> Cheers
> Joe
> 
> On Wed, 6 Feb 2019 at 17:31, Nikita Popov  <mailto:nikita@gmail.com>> wrote:
> 
> On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/6/19 11:50 AM, Nikita Popov wrote:
>  > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins
> mailto:krak...@gmail.com>> wrote:
>  >
>  >> Afternoon internals,
>  >>
>  >> Some time ago I brought up for discussion:
>  >> https://wiki.php.net/rfc/abolish-narrow-margins
>  >>
>  >> I intend to bring this up for vote in the next few days.
>  >>
>  >> Cheers
>  >> Joe
>  >>
>  >
>  > After one day of heated discussion this thread has died down
> again. I'd
>  > like to make sure that there are no further concerns here
> before this goes
>  > to vote.
>  >
>  > Most of the discussion here has been around the question of
> whether or not
>  > this should be part of Zeev's RFC (and it doesn't look like
> we're going to
>  > agree on that one), but there has been little further
> discussion of the
>  > proposal itself. I guess that means it's fairly uncontroversial.
>  >
>  > As far as I can see the only difference between this proposal
> and Zeev's
>  > (as far as voting margins are concerned), is that this RFC
> requires a 2/3
>  > majority, while Zeev's proposal excludes "PHP Packaging
> Decisions" and only
>  > requires a simple majority for them.
>  >
>  > There has been some brief discussion about this, with the
> following mail
>  > from Stas:
>  >
>  >> 1. Do we really need different classification of changes? I
> think having
>  >> one single vote procedure would have larger benefit, and RFC
> that fails
>  >> 2/3 requirement would be suspect anyway. RFCs can have parts
> - "whether
>  >> we do it" and "how exactly we do it" - the former would be 2/3
>  >> requirement, the latter can be simple plurality even - e.g.
> if we decide
>  >> to have an extension for libfoobar, that should have 2/3
> vote, but then
>  >> decision between whether to name it foobar or barfoo can be
> decided by
>  >> majority or plurality.
>  >
>  > And Zeev's response:
>  >
>  >> I think we do.  There are decisions where a 2/3 majority
> requirement makes
>  >> no sense, as the vote itself is about a choice between two
> options that
>  > are
>  >> on the table, as opposed to deciding whether to do something
> or not.
>  >> There aren't many such cases, but when they do occur - they
> tend to be
>  >> important.
>  >>
>  >> The most obvious case I have in mind is that of the choice
> between PHP 6
>  >> and 7.  It doesn't expose us to any future commitments,
> doesn't change the
>  >> language - it's arguably almost a marketing decision. 
> Similarly, if we
>  >> 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

On 2/6/19 11:50 AM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins  wrote:
> 
>> Afternoon internals,
>>
>> Some time ago I brought up for discussion:
>> https://wiki.php.net/rfc/abolish-narrow-margins
>>
>> I intend to bring this up for vote in the next few days.
>>
>> Cheers
>> Joe
>>
> 
> After one day of heated discussion this thread has died down again. I'd
> like to make sure that there are no further concerns here before this goes
> to vote.
> 
> Most of the discussion here has been around the question of whether or not
> this should be part of Zeev's RFC (and it doesn't look like we're going to
> agree on that one), but there has been little further discussion of the
> proposal itself. I guess that means it's fairly uncontroversial.
> 
> As far as I can see the only difference between this proposal and Zeev's
> (as far as voting margins are concerned), is that this RFC requires a 2/3
> majority, while Zeev's proposal excludes "PHP Packaging Decisions" and only
> requires a simple majority for them.
> 
> There has been some brief discussion about this, with the following mail
> from Stas:
> 
>> 1. Do we really need different classification of changes? I think having
>> one single vote procedure would have larger benefit, and RFC that fails
>> 2/3 requirement would be suspect anyway. RFCs can have parts - "whether
>> we do it" and "how exactly we do it" - the former would be 2/3
>> requirement, the latter can be simple plurality even - e.g. if we decide
>> to have an extension for libfoobar, that should have 2/3 vote, but then
>> decision between whether to name it foobar or barfoo can be decided by
>> majority or plurality.
> 
> And Zeev's response:
> 
>> I think we do.  There are decisions where a 2/3 majority requirement makes
>> no sense, as the vote itself is about a choice between two options that
> are
>> on the table, as opposed to deciding whether to do something or not.
>> There aren't many such cases, but when they do occur - they tend to be
>> important.
>>
>> The most obvious case I have in mind is that of the choice between PHP 6
>> and 7.  It doesn't expose us to any future commitments, doesn't change the
>> language - it's arguably almost a marketing decision.  Similarly, if we
>> decide to change our release schedule, I don't see why that should require
>> a 2/3 majority.  The 'bias for the status quo', which is the main reason
> we
>> have the super majority requirement to begin with, doesn't really play a
>> role here - as it bears no long term commitment.
> 
> I'll add my own response here. I agree with Stas that it is preferable to
> have a single voting procedure and don't think that "packaging decisions"
> should be special cased. This is not just to in the interest of having
> simple rules, but also because I disagree with the premise that packaging
> decisions are somehow less important than changes to PHP or do not have
> future commitments. For example, extending support for a release by
> multiple years (a question that will probably come up for PHP 7.4), is a
> quite serious commitment of resources that should not be decided on a
> narrow margin.
> 
> More importantly, while our past RFCs in the area of "packaging" have not
> been particularly major, that's isn't a property inherent to the category.
> For example, a proposal to introduce regular LTS releases, or to make other
> major changes to our release scheduling, should certainly be subject to a
> 2/3 majority. In each category (whether it's changes to PHP or the release
> process) there will always be more and less significant RFCs, and it's hard
> to draw a good line between them (we failed spectacularly trying to due
> that with "language changes"). I think it is better to err on the side of
> being conservative and require a 2/3 majority for everything, especially as
> it also obviates any arguments as to what requires or doesn't require a
> certain majority.

First, take the words from this RFC: "Anything merged into php-src is by 
definition a core part of PHP, regardless of the folder it goes into, or 
whether it has direct implications for our users. This is not a 
debatable fact: If it is distributed with PHP, it is core software".

Does this mean that every merge into php-src requires vote?
If not, why this sentence is here?

Second, many significant internal improvements don't affect PHP behavior 
at all. Usually, they affect just few core developers and few 
third-party extensions maintainers. Should this really require super 
majority of all the voters? Or we can avoid voting, instead?

We currently have voting rules, that more or less work.

In case, anyone like to change them, it would be better to present new 
rules as a "DIFF" on top of existing ones (in the most possible compact, 
clear and formal way). Then we may vote on the whole "DIFF", or each 
change separately.

I wouldn't vote for changes of rules without clear context.
I hate politics, and wouldn't like to participate 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/6/19 12:26 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/3/19 9:00 PM, Nikita Popov wrote:
>  > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  <mailto:vsura...@gmail.com>> wrote:
>  >
>  >>
>  >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  <mailto:php...@ehrhardt.nl>> wrote:
>  >>>
>  >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>  >>>>
>  >>>>
>  >>>> How is that related?
>  >>>
>  >>> It is directly related with your statement that "developers
> with other
>  >>> host OSs still use Linux for the actual PHP development". They
> don't use
>  >>> Linux for the actual PHP development. They are using Windows.
>  >>
>  >> That statement was in a certain context - for those who use
> containers and
>  >> Linux VMs, which is (as mentioned) a growing trend.  I think
> it's clear
>  >> that I'm not claiming it's everyone, or even the majority - but
> if it
>  >> wasn't clear - it should be now...
>  >>
>  >> Zeev
>  >>
>  >
>  > I feel like this discussion ended up going a bit astray, with a
> focus on
>  > only the issue of Windows support... While I think that we should
> endeavor
>  > to support at least Windows and MacOS before the JIT hits a
> release version
>  > of PHP, at this point in time (and for the purposes of the vote) the
>  > questions of maintenance and stability are the most important.
> 
> If we don't start, we definitively won't get support.
> 
> 
>  > Ultimately
>  > those questions can't really be answered until interested parties
> have
>  > reviewed the JIT codebase. To that end it would be helpful if:
>  >
>  > a) A PR of the JIT branch could be submitted against php-src, so
> there is a
>  > place for review comments and more technical discussions. (It
> might be
>  > necessary to squash, as GH doesn't deal with large history well.)
> 
> OK. Not sure about re-base.
> 
>  > b) The RFC (or some other place) is extended with some high-level
> design
>  > information on how the JIT works on a technical level. Some notes
> on how
>  > JIT bugs are usually debugged would also be very helpful.
> 
> 
> OK. I'll try to extend RFC with some design elements.
> 
> Thanks. Dmitry.
> 
> 
> As you probably spent a lot of time profiling the JIT, I'm wondering if 
> you have any insights about what the main issues are right now that 
> prevent better performance and what some idea to improve those would be.

Real-life apps more suffer from bad data locality and data set size.
One of the metric that shows, how good/bad progam is executes is CPI 
(Cycles per Instruction). You may measure it using Linux perf (perf 
stat) or estimate using callgrind.

For bench.php it's 0.5, for Wordpress 1.2. This means that Wordpress 
waste significantly more CPU time because of different stalls.

Even if we improve execution, using JIT, and reduce the amount of 
executed instructions, this doesn't proportionally affects CPU cycles 
(and time), because many data related stalls are still there.

> E.g. I don't think the JIT currently does any inlining (right?) and that 
> might be something that could give a benefit?

Absolutely.

Currently JIT keeps VM state in consistency, when it calls any standard 
VM handler, emits error/warning, throw exception, and just call any PHP 
API function. But this is not necessary for most fast paths.

And this is the challenge for the next JIT improvement iteration.

1) Instead of immediate JIT-ing the whole function after hot-counter 
triggering, we will perform low-cost initial profiling, collecting jump 
probabilities, real run-time types and values.

2) Then we will generate code only for fast paths, especially optimized 
for our cases (information, collected during profiling). This code is 
not going to keep the VM state and may implement inlining of PHP 
functions and other smart optimizations.

3) The fast-path code is going to include "guard" check for transitions 
to slow paths that were never executes during profiling, but that can't 
be eliminated by static analyses (SSA info).

4) In case of guard failure, we should jump form JIT execution to VM, 
restoring the VM state consistency. This process named "deoptimization".

I would recommend, spend some time reading related V8 presentations.

https://v8.dev/docs/turbofan


Thanks. Dmitry.

> 
> Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote:
> Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller :
>> Shouldn't we introduce annotations instead of relying on doc comments?
> 
> Yeah I'm not too happy with that approach either. I would rather see
> another way to do this and like you said; annotations is probably the
> best way to go about it as introducing a new keyword is not very
> suitable imo.
> 

Attributes were proposed ~3 years ago.

https://wiki.php.net/rfc/attributes

There were few other releted proposals.
But they didn't pass.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> 
> 
> On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
>  >
>  >
>  > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei
> mailto:kont...@beberlei.de>
>  > <mailto:kont...@beberlei.de <mailto:kont...@beberlei.de>>> wrote:
>  >
>  >
>  >
>  >     On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> mailto:dmi...@zend.com>
>  >     <mailto:dmi...@zend.com <mailto:dmi...@zend.com>>> wrote:
>  >
>  >         Hi Internals,
>  >
>  >
>  >         I'm glad to finally propose including JIT into PHP.
>  >
>  >
>  > https://wiki.php.net/rfc/jit
>  >
>  >
>  >         In the current state it may be included both into PHP-8,
> where
>  >         we are going to continue active improvement, and into
> PHP-7.4,
>  >         as an experimental feature.
>  >
>  >
>  >     Can you give some information on if there are pre-conditions that
>  >     must hold for a function to be jitted, or quit conditions
> that force
>  >     the JIT to be reverted for a function?
> 
> -dopcache.jit=1245 will lead to JIT only functions with @jit
> doc-comment
> tag. It's possible to extend this manual control.
> 
> 
> @jit works if I have full control over my code-base, but whenever I use 
> libraries/frameworks this kind of configuration is too static, and puts 
> a burden on open-source maintainers to figure out what they want to jit 
> or not for users.
> 
> This option will not be very useful from a distributed maintenance 
> perspective, especially if you don't know if users pick 4 or 3, this is 
> too much configuration details/micro-management in my opinion, 
> especially given your argument that JIT is supposed to be as transparent 
> and behind the scenes as possible for users.
> 
> In my opinion 4 should not be available to users.

In some cases it may help (similar to "inline" in C).
For better performance, I would recomend "hot counters trigger" - 3 or 
everything - 0.

> 
> 
>  >     In addition, it would be
>  >     helpful for testing if there was a way to find out if a
> function was
>  >     jitted, maybe through ReflectionMethod/Function or
>  >     opcache_get_status() ?
> 
> yes. This makes sense.
> 
>  >
>  > And as a follow up, the JIT seems to affect zend_execute_ex and
>  > zend_execute_internal based profiling (tested with
> tideways_xhprof) in a
>  > way that all Jitted functions are not called through those two hooks
>  > anymore, and don't appear in profiling data anymore. Is that a
> correct
>  > description? The number of parent=>child call entries drops from
> 88 to
>  > 12 in my sample code when jit is activated.
>  >
>  > Is that a desired side-effect?
> 
> Yes. This is, at least expected.
> PHP profilers/debuggers may disable JIT and opcache for particular
> request, setting "opcache.enable=0" in RINIT.
> 
> 
> This may be acceptable for development profilers, but it is not for 
> production profiling such as Blackfire and Tideways. I see that 
> overwriting internal function pointers still works for hooks, so that 
> doesn't need improvement, but PHP extensions need a way to control 
> zend_execute_ex behavior, or get an alternative hook for jit based 
> execution.

JIT doesn't make a lot of sense if it doesn't optimize the overhead of 
interpretation (nested calls to execute_ex, etc). It's clear, that it's 
more difficult to debug optimized native code. Most implementations 
fallback to interpretation when need debugging. Profiling of optimized 
code is possible, but requires additional hooks.

> For Xhprof style profilers, a hook that gets the class + function name 
> alone would be enough.
> 
> For tracing profilers based on a whitelist of a few instrumented 
> functions like tideways, NewRelic and probably all other APM vendor 
> extensions, there needs to be a hook to selectively decide "don't JIT 
> this function", that can be hooked into from 0 to many extensions.
> Example, Tideways hooks into the userland function Mage::logException(), 
> to detect that Magento has thrown an exception that leads to a 500 page 
> being rendered. It should be possible to make sure this function never 
> gets jitted, so that I see its execution in zend_execute_ex