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

2022-01-17 Thread 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?

2022-01-16 Thread 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

2021-11-10 Thread 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

2021-09-01 Thread 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

2021-08-30 Thread 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

2021-07-07 Thread 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

2021-07-05 Thread 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

2021-06-15 Thread 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

2021-06-11 Thread 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

2021-06-11 Thread 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

2021-04-07 Thread 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

2021-03-19 Thread 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

2021-03-19 Thread 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

2021-03-10 Thread 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

2021-03-05 Thread 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

2021-03-04 Thread 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

2021-03-04 Thread 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

2021-03-04 Thread 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

2021-03-04 Thread 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

2021-03-04 Thread 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

2021-02-25 Thread 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

2021-02-25 Thread 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

2021-02-08 Thread 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

2021-02-05 Thread 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

2020-12-15 Thread 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

2020-11-26 Thread 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

2020-11-24 Thread 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

2020-11-24 Thread 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

2020-11-23 Thread 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

2020-10-29 Thread 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

2020-09-28 Thread 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

2020-09-14 Thread 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

2020-08-06 Thread 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

2020-06-02 Thread 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

2019-11-05 Thread 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

2019-10-25 Thread 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

2019-10-25 Thread 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

2019-10-23 Thread 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

2019-10-22 Thread 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"

2019-10-10 Thread 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"

2019-10-07 Thread 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

2019-09-18 Thread 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

2019-06-13 Thread 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

2019-03-29 Thread 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

2019-03-29 Thread 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

2019-03-29 Thread 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

2019-03-21 Thread 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

2019-03-21 Thread 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

2019-03-21 Thread 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

2019-03-15 Thread 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

2019-03-05 Thread 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

2019-02-26 Thread 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

2019-02-22 Thread 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

2019-02-22 Thread 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

2019-02-15 Thread 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

2019-02-15 Thread 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

2019-02-14 Thread 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

2019-02-14 Thread 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

2019-02-14 Thread 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

2019-02-13 Thread 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

2019-02-13 Thread 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

2019-02-13 Thread 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

2019-02-13 Thread 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

2019-02-13 Thread 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

2019-02-06 Thread 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

2019-02-06 Thread 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

2019-02-06 Thread 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

2019-02-06 Thread 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

2019-02-05 Thread 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

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Dmitry Stogov


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>> wrote:
> 
> 
> 
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  <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.

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

In addition, JIT-ed functions now may be tracked by Linux perf (oprofile 
and Intel VTune).

$ perf record php -d opcache.huge_code_pages=0 -d opcache.jit_debug=0x10 
bench.php
$ perf report

Thanks. Dmitry.



> 
> 
> 
> Thanks. Dmitry.
> 


Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Dmitry Stogov


On 2/4/19 11:39 PM, Bruce Weirdan wrote:
> After figuring out that opcache.jit_buffer_size is specified in bytes
> (not in megabytes, as RFC states)

Thanks for catching this. Fixed.

> I got ~5% speedup running
> vimeo/psalm (static analyzer) on its own codebase with default
> JIT flags and ~7.3% with minimal JIT (1201).
> 
> 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.

Thanks. Dmitry.


Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Dmitry Stogov


On 2/4/19 6:22 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/4/19 5:44 PM, Nikita Popov wrote:
>  > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  <mailto:dmi...@zend.com>
>  > <mailto:dmi...@zend.com <mailto:dmi...@zend.com>>> wrote:
>  >
>  >
>  >
>  >     On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>  >      >
>  >      >
>  >      > On 2/1/19 3:09 PM, Nikita Popov wrote:
>  >      >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> mailto:dmi...@zend.com>
>  >     <mailto:dmi...@zend.com <mailto:dmi...@zend.com>>
>  >      >> <mailto:dmi...@zend.com <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.
>  >      >>
>  >      >>
>  >      >>      Thanks. Dmitry.
>  >      >>
>  >      >>
>  >      >> I would like to check if the JIT provides an improvement for
>  >     PHP-Parser.
>  >      >> Unfortunately I'm getting a segfault when running the tests.
>  >     Should be
>  >      >> reproducible with
>  >      >>
>  >      >> git clone g...@github.com:nikic/PHP-Parser.git
>  >      >> cd PHP-Parser
>  >      >> composer install
>  >      >> php-jit vendor/bin/phpunit
>  >      >>
>  >      >> I tried to debug this. Unfortunately my gdb doesn't seem
> to work
>  >     with
>  >      >> JIT: It hangs when the script starts running, on line
>  >     Zend/zend_gdb.c:84
>  >      >> in zend_gdb_register_code. I don't know if that's a bug or I
>  >     need to do
>  >      >> something additional here (I'm using GNU gdb (Ubuntu
> 8.1-0ubuntu3)
>  >      >> 8.1.0.20180409-git).
>  >      >
>  >      > GDB takes enormous time registering too many JIT-ed
> functions...
>  >      > It should be possible to catch the name of problematic
> functions
>  >     and the
>  >      > JIT only them (using PHPDOC trigger). I'll try to analyze the
>  >     crash, but
>  >      > most probably, only on next week.
>  >
>  >     I fixed the problem caused JIT to fail on PHP-Parser tests
> (it was
>  >     related to changes introduced by typed properties patch).
>  >
>  >     I'm also going to disable automatic JIT code registration in GDB.
>  >
>  >     Thanks. Dmitry.
>  >
>  >
>  > Thanks. I was now able to run a PHP-Parser benchmark, which
> showed ~1.5x
>  > speedup with default JIT configuration. That's promising :)
>  >
>  > Next I want to try https://github.com/amphp/hpack (part of HTTP 2
>  > implementation), where I also expect good results. Currently
> there is a
>  > segfault while running tests.
> 
> Could you provide a quick instruction, how to reproduce this (in the
> same way like with PHP-Parser).
> 
> 
> The reproduce steps are basically the same in this case, just on a 
> different repo:
> 
> git clone g...@github.com:amphp/hpack.git
> cd hpack
> composer install
> php-jit vendor/bin/phpunit
> 
> Nikita

Fixed.


Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Dmitry Stogov


On 2/4/19 5:44 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>  >
>  >
>  > On 2/1/19 3:09 PM, Nikita Popov 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.
>  >>
>  >>
>  >>      Thanks. Dmitry.
>  >>
>  >>
>  >> I would like to check if the JIT provides an improvement for
> PHP-Parser.
>  >> Unfortunately I'm getting a segfault when running the tests.
> Should be
>  >> reproducible with
>  >>
>  >> git clone g...@github.com:nikic/PHP-Parser.git
>  >> cd PHP-Parser
>  >> composer install
>  >> php-jit vendor/bin/phpunit
>  >>
>  >> I tried to debug this. Unfortunately my gdb doesn't seem to work
> with
>  >> JIT: It hangs when the script starts running, on line
> Zend/zend_gdb.c:84
>  >> in zend_gdb_register_code. I don't know if that's a bug or I
> need to do
>  >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>  >> 8.1.0.20180409-git).
>  >
>  > GDB takes enormous time registering too many JIT-ed functions...
>  > It should be possible to catch the name of problematic functions
> and the
>  > JIT only them (using PHPDOC trigger). I'll try to analyze the
> crash, but
>  > most probably, only on next week.
> 
> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> related to changes introduced by typed properties patch).
> 
> I'm also going to disable automatic JIT code registration in GDB.
> 
> Thanks. Dmitry.
> 
> 
> Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x 
> speedup with default JIT configuration. That's promising :)
> 
> Next I want to try https://github.com/amphp/hpack (part of HTTP 2 
> implementation), where I also expect good results. Currently there is a 
> segfault while running tests.

Could you provide a quick instruction, how to reproduce this (in the 
same way like with PHP-Parser).

Thanks. Dmitry.

> 
> Nikita


Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Dmitry Stogov


On 2/4/19 1:32 PM, Andrea Faulds wrote:
> 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.
>>
> 
> Hi Dmitry,
> 
> Thank you for making an RFC for this. That makes it possible to have a 
> proper discussion about the JIT idea.
> 
> A concern I have with the current RFC is a lack of a good case for why 
> it should be necessary; the case for JIT is based on performance 
> benefits, but the examples provided are unconvincing to me because they 
> seem too contrived. Both bench.php and drawing fractals represent a 
> best-case example for a JIT, small programs which do heavy arithmetic 
> and not much else. Maybe PHP being able to be used for this kind of 
> software would be cool, but it wouldn't justify the added complexity 
> (and for that matter security headaches) of adding a JIT to PHP given C, 
> C++, FORTRAN and so on already exist and are better-suited to it.
> 
> I guess what I am saying is that the JIT RFC could benefit from 
> real-world examples that show a benefit to having it. The ideal 
> application is something in between WordPress and your Mandelbrot 
> example, one which has significant complexity (i.e. a plausible 
> real-world application), hot code which a JIT can actually make notably 
> faster than the current Zend VM, and is something not *too* far away 
> from the kinds of applications people write in PHP today — even if you 
> *could* write applications focussed on high-performance heavy 
> number-crunching in PHP, I don't expect people would want to, even if it 
> becomes less slow.

I've added info from Nikita: PHP-Parser became 1.5 times faster.

Thanks. Dmitry.

> 
> Thanks,
> Andrea
> 

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


Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Dmitry Stogov


On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> 
> 
> On 2/1/19 3:09 PM, Nikita Popov wrote:
>> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > <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.
>>
>>
>>  Thanks. Dmitry.
>>
>>
>> I would like to check if the JIT provides an improvement for PHP-Parser.
>> Unfortunately I'm getting a segfault when running the tests. Should be
>> reproducible with
>>
>> git clone g...@github.com:nikic/PHP-Parser.git
>> cd PHP-Parser
>> composer install
>> php-jit vendor/bin/phpunit
>>
>> I tried to debug this. Unfortunately my gdb doesn't seem to work with
>> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
>> in zend_gdb_register_code. I don't know if that's a bug or I need to do
>> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>> 8.1.0.20180409-git).
> 
> GDB takes enormous time registering too many JIT-ed functions...
> It should be possible to catch the name of problematic functions and the
> JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
> most probably, only on next week.

I fixed the problem caused JIT to fail on PHP-Parser tests (it was 
related to changes introduced by typed properties patch).

I'm also going to disable automatic JIT code registration in GDB.

Thanks. Dmitry.

> 
> Thanks. Dmitry.
> 
>>
>> Nikita
> 


Re: [PHP-DEV] [RFC] JIT

2019-02-03 Thread Dmitry Stogov


On 2/3/19 9:00 PM, Nikita Popov wrote:
> On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:
> 
>>
>>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  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.

> 
> Regards,
> Nikita
> 

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


Re: [PHP-DEV] [RFC] JIT

2019-02-03 Thread Dmitry Stogov



On 2/1/19 7:30 PM, Larry Garfield wrote:
> On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote:
>> On 2/1/19 3:29 AM, Larry Garfield wrote:
> 
>>> Question from a non-compiler-engineer: Could we end up in a situation
>>> where
>>> future language features (in 8.3 or something) are only performant on JIT-
>>> enabled platforms?  I know there were some RFCs rejected in the past on
>>> the
>>> grounds that they involved too many runtime checks (and thus a performance
>>> hit); if it were possible for a JIT to optimize some of those away, it
>>> might make the cost acceptable.  However, if a JIT only works on some
>>> systems that might widen the gap between have- and have-not platforms.
>>
>> I think, JIT only approach doesn't make a lot of sense for PHP, with one
>> of the most fast VM. And this is a trend. Even V8, starting from JIT
>> only, switched back to VM+JIT.
>>
>> Thanks. Dmitry.
> 
> I'm... not sure how that answers my question?  I'm saying "if we had a VM+JIT,
> and the JIT part made feature X acceptably fast but it wasn't acceptably fast
> with just the VM, is that a problem?"  Or is that a situation that cannot
> happen?  Or that we don't care if it happens?

Everything is possible, but I don't think very realistic now.
When some features are going to depend on JIT, we might have much better 
JIT then now.

Thanks. Dmitry.

> 
> --Larry Garfield
> 

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



Re: [PHP-DEV] [RFC] JIT

2019-02-01 Thread Dmitry Stogov


On 2/1/19 4:23 PM, Nikita Popov wrote:
> On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/1/19 11:55 AM, Joe Watkins wrote:
>  > Morning Dmitry, and internals,
>  >
>  > This is marvellous stuff, truly brilliant. I particularly
> appreciate the
>  > non-intrusive approach of setting jit'd code as the opcode
> handler, this
>  > makes life a little easier for hacky extension authors, I think.
>  >
>  > As others have said:
>  >
>  >    I don't like the idea of omitting to support windows, less
> worried
>  > about fancy architectures.
> 
> I can provide help to people who will going to implement JIT support
> for
> Windows. This is not going to be easy, because MSVC doesn't support
> "hybrid VM" and "global register variables", therefore the code is
> going
> to be more expensive.
> 
> 
> I think an important point here is that this issue affects not only 
> Windows: It also affects any platform that uses clang as their compiler. 
> Notably this includes MacOS.
> 
> Clang theoretically supports global registers, but only for 
> non-allocatable regs (rsp and rbp), which I think is not very useful for 
> this purpose.

We will have to provide a patch for CLANG, implementing PHP VM calling 
convention (HHVM, Erlang, Haskel did this).

Thanks. Dmitry.

> 
> So this problem needs to be solved not just for Windows support, but 
> also for MacOS support (and also FreeBSD and other clang-using platforms).
> 
> Nikita
> 
>  >    I'm not keen on the idea that there is no way to debug the
> code this
>  > generates outside of GDB, and I'm not sure how useful gdb will
> be: I've
>  > tried to debug JIT'd code in that before and it doesn't do so
> well, but
>  > I could easily have been doing it wrong. I'd be very happy to be
>  > corrected about this ?
> 
> I'm not sure, what is wrong with GDB, and if any other debuggers have
> special API for run-time generated code.
> 
>  >    I'm not keen on the idea of merging this into 7.4, for various
>  > reasons that don't need to be repeated.
> 
> OK. It's not only your opinion.
> You may vote against, and persuade others.
> 
>     Thanks. Dmitry.
> 
>  >
>  > Bottom line though, I love it, it's brilliant, and look forward
> to PHP 8.
>  >
>  > Thank you, Dmitry.
>  >
>  > Cheers
>  > Joe
>  >
>  >
>  > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  <mailto:dmi...@zend.com>
>  > <mailto:dmi...@zend.com <mailto:dmi...@zend.com>>> wrote:
>  >
>  >
>  >
>  >     On 2/1/19 3:29 AM, Larry Garfield wrote:
>  >      > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler
> wrote:
>  >      >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski
> mailto:z...@php.net>
>  >     <mailto:z...@php.net <mailto:z...@php.net>>> wrote:
>  >      >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
>  >     mailto:ka...@php.net> <mailto:ka...@php.net
> <mailto:ka...@php.net>>>
>  >      >>>
>  >      >>> wrote:
>  >      >>>> Without my usual Windows bias, I do believe it is a
>  >     considerable fact
>  >      >>>> like Nikita pointed out as Windows is a first class
> citizen in
>  >     terms
>  >      >>>> of operating systems we support. While PHP on Windows
> may not
>  >     have the
>  >      >>>> speed that the Unix counterpart have, it is still a
> very important
>  >      >>>> development platform. Many developers develop on
> Windows and
>  >     deploy on
>  >      >>>> a Unix based system, being unable to test such an important
>  >     feature in
>  >      >>>> a development environment is also a large question mark.
>  >      >>>
>  >      >>> As long as we can agree that very few actually *deploy *on
>  >     Windows, I
>  >      >>> think
>  >      >>> we're on solid grounds.
>  >      >>> As the JIT implementation is likely to have at least *some*
>  >     significant
>  >      >>> differences compared to Linux, I'm not sure wh

Re: [PHP-DEV] [RFC] JIT

2019-02-01 Thread Dmitry Stogov


On 2/1/19 3:09 PM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  <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.
> 
> 
> Thanks. Dmitry.
> 
> 
> I would like to check if the JIT provides an improvement for PHP-Parser. 
> Unfortunately I'm getting a segfault when running the tests. Should be 
> reproducible with
> 
> git clone g...@github.com:nikic/PHP-Parser.git
> cd PHP-Parser
> composer install
> php-jit vendor/bin/phpunit
> 
> I tried to debug this. Unfortunately my gdb doesn't seem to work with 
> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84 
> in zend_gdb_register_code. I don't know if that's a bug or I need to do 
> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3) 
> 8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the 
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but 
most probably, only on next week.

Thanks. Dmitry.

> 
> Nikita

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


Re: [PHP-DEV] [RFC] JIT

2019-02-01 Thread Dmitry Stogov


On 2/1/19 2:12 PM, Pierre Joye wrote:
> 
> 
> On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov  <mailto:dmi...@zend.com> wrote:
> 
> 
> 
> I don't see any problems with including JIT without Windows support.
> Windows runs PHP much slower any way.
> 
> 
> How so? I tend to disagree here. Except if recent changes affect Windows 
> indirectly (as in optimization done on linux only).

More or less right. PHP uses GCC extensions, that are not available in MSVC.

> Also while I use php on windows less, I still see a large amount of 
> companies using php on windows,  in similar ways than on Linux.
> 
> Nikita concerns are valid, PHP is and should remain a cross platform 
> language. And some top OSes besides linux should remain a target. Easier 
> said than done and willing to help at least for windows. I am sure msft 
> teams will step in as well.

It would be great, if MSFT team helps.
I definitely, can't move JIT forward, and provide support for all 
platforms at the same time.

Thanks. Dmitry.




Re: [PHP-DEV] [RFC] JIT

2019-02-01 Thread Dmitry Stogov


On 2/1/19 11:55 AM, Joe Watkins wrote:
> Morning Dmitry, and internals,
> 
> This is marvellous stuff, truly brilliant. I particularly appreciate the 
> non-intrusive approach of setting jit'd code as the opcode handler, this 
> makes life a little easier for hacky extension authors, I think.
> 
> As others have said:
> 
>    I don't like the idea of omitting to support windows, less worried 
> about fancy architectures.

I can provide help to people who will going to implement JIT support for 
Windows. This is not going to be easy, because MSVC doesn't support 
"hybrid VM" and "global register variables", therefore the code is going 
to be more expensive.

>    I'm not keen on the idea that there is no way to debug the code this 
> generates outside of GDB, and I'm not sure how useful gdb will be: I've 
> tried to debug JIT'd code in that before and it doesn't do so well, but 
> I could easily have been doing it wrong. I'd be very happy to be 
> corrected about this ?

I'm not sure, what is wrong with GDB, and if any other debuggers have 
special API for run-time generated code.

>    I'm not keen on the idea of merging this into 7.4, for various 
> reasons that don't need to be repeated.

OK. It's not only your opinion.
You may vote against, and persuade others.

Thanks. Dmitry.

> 
> Bottom line though, I love it, it's brilliant, and look forward to PHP 8.
> 
> Thank you, Dmitry.
> 
> Cheers
> Joe
> 
> 
> On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> 
> 
> On 2/1/19 3:29 AM, Larry Garfield wrote:
>  > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
>  >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  <mailto:z...@php.net>> wrote:
>  >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
> mailto:ka...@php.net>>
>  >>>
>  >>> wrote:
>  >>>> Without my usual Windows bias, I do believe it is a
> considerable fact
>  >>>> like Nikita pointed out as Windows is a first class citizen in
> terms
>  >>>> of operating systems we support. While PHP on Windows may not
> have the
>  >>>> speed that the Unix counterpart have, it is still a very important
>  >>>> development platform. Many developers develop on Windows and
> deploy on
>  >>>> a Unix based system, being unable to test such an important
> feature in
>  >>>> a development environment is also a large question mark.
>  >>>
>  >>> As long as we can agree that very few actually *deploy *on
> Windows, I
>  >>> think
>  >>> we're on solid grounds.
>  >>> As the JIT implementation is likely to have at least *some*
> significant
>  >>> differences compared to Linux, I'm not sure what testing it on
> Windows
>  >>> would give you.  JIT is supposed to be entirely transparent,
> and the
>  >>> performance characteristics - as well as the bug patterns - are
> likely to
>  >>> be quite different on Linux vs. Windows, at least in many cases.
>  >>> Is it really that important to have?
>  >>>
>  >>> I'm honestly a bit perplexed by how many people here viewing
> Windows
>  >>> support as a must have, while at the same time I think we all
> agree PHP is
>  >>> very scarcely found on production Windows servers, and JIT is a
>  >>> predominantly production feature.
>  >>>
>  >>> I'm personally interested in taking a look at it (and I'm certain
>  >>>
>  >>>> Anatol does too), but simply dismissing is a no-go for me.
>  >>>
>  >>> It'd be interesting to evaluate the cost associated with supporting
>  >>> Windows.  Bare in mind, we're proposing to vote on this as a
> production
>  >>> feature for PHP 8 - which realistically means almost two years
> from now
>  >>> *at
>  >>> the earliest*.  I'm sure we'd have Windows support a lot sooner
> than that
>  >>> if we decide that it's a must have.  I agree with Nikita that
> the key
>  >>> question is in fact, do we or do we not want to introduce JIT
> in - with
>  >>> the
>  >>> main question being the maintenance cost.  Let's tackle this
> question
>  >>> first, otherwise - why send Dmitry (and maybe others) for doing
&g

Re: [PHP-DEV] [RFC] JIT

2019-02-01 Thread Dmitry Stogov



On 2/1/19 3:29 AM, Larry Garfield wrote:
> On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
>> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  wrote:
>>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen 
>>>
>>> wrote:
 Without my usual Windows bias, I do believe it is a considerable fact
 like Nikita pointed out as Windows is a first class citizen in terms
 of operating systems we support. While PHP on Windows may not have the
 speed that the Unix counterpart have, it is still a very important
 development platform. Many developers develop on Windows and deploy on
 a Unix based system, being unable to test such an important feature in
 a development environment is also a large question mark.
>>>
>>> As long as we can agree that very few actually *deploy *on Windows, I
>>> think
>>> we're on solid grounds.
>>> As the JIT implementation is likely to have at least *some* significant
>>> differences compared to Linux, I'm not sure what testing it on Windows
>>> would give you.  JIT is supposed to be entirely transparent, and the
>>> performance characteristics - as well as the bug patterns - are likely to
>>> be quite different on Linux vs. Windows, at least in many cases.
>>> Is it really that important to have?
>>>
>>> I'm honestly a bit perplexed by how many people here viewing Windows
>>> support as a must have, while at the same time I think we all agree PHP is
>>> very scarcely found on production Windows servers, and JIT is a
>>> predominantly production feature.
>>>
>>> I'm personally interested in taking a look at it (and I'm certain
>>>
 Anatol does too), but simply dismissing is a no-go for me.
>>>
>>> It'd be interesting to evaluate the cost associated with supporting
>>> Windows.  Bare in mind, we're proposing to vote on this as a production
>>> feature for PHP 8 - which realistically means almost two years from now
>>> *at
>>> the earliest*.  I'm sure we'd have Windows support a lot sooner than that
>>> if we decide that it's a must have.  I agree with Nikita that the key
>>> question is in fact, do we or do we not want to introduce JIT in - with
>>> the
>>> main question being the maintenance cost.  Let's tackle this question
>>> first, otherwise - why send Dmitry (and maybe others) for doing more work
>>> (Windows support) if we are likely to flush it all down the toilet?
>>>
>> Maybe we're the only ones, but we run production PHP on Windows. I have no
>> issues with the idea of not initially having support for Windows. I can
>> probably even live with never having support for Windows - provided that we
>> don't find ourselves in a situation like Nikita mentioned where features
>> start getting developed in PHP instead of C and require JIT in order to
>> function.
> 
> Question from a non-compiler-engineer: Could we end up in a situation where
> future language features (in 8.3 or something) are only performant on JIT-
> enabled platforms?  I know there were some RFCs rejected in the past on the
> grounds that they involved too many runtime checks (and thus a performance
> hit); if it were possible for a JIT to optimize some of those away, it might
> make the cost acceptable.  However, if a JIT only works on some systems that
> might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one 
of the most fast VM. And this is a trend. Even V8, starting from JIT 
only, switched back to VM+JIT.

Thanks. Dmitry.

> 
> Is that a concern, or am I making things up?  Or, is it a concern but we're
> legit OK with that happening (which is also an entirely valid decision to
> make)?
> 
> --Larry Garfield
> 

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



Re: [PHP-DEV] [RFC] JIT

2019-01-31 Thread Dmitry Stogov


On 1/31/19 9:12 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> 
>>
>>
>> On 1/31/19 8:08 PM, Derick Rethans wrote:
>>> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
>>>
>>>> I'm glad to finally propose including JIT into PHP.
>>>>
>>>> https://wiki.php.net/rfc/jit
>>>
>>> I don't see anywhere in this RFC how it would affect thigns that do
>>> sneaky things with internals, such as Xdebug. How is that going to be
>>> affected?
>>>
>>
>> I suppose Xdebug should work on non-JIT-ed versions of the functions.
>> Even JVM deoptimizes to bytecode when debugging.
> 
> So, in that case, I think I would need to be able to instruct the PHP
> JIT engine to be turned off. Perhaps through an API?
> 
> Similarly, I think it might be useful for OPcache as well,

Use zend_alter_ini_entry() to set "opcache.enable" to "0".
Better to do it at RINIT.

Thanks. Dmitry.

> as I am
> getting more people confused why some breakpoints don't work, or
> variables don't exist:
> https://bugs.xdebug.org/view.php?id=1609
> 
> cheers,
> Derick
> 

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


Re: [PHP-DEV] [RFC] JIT

2019-01-31 Thread Dmitry Stogov


On 1/31/19 8:08 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> 
>> I'm glad to finally propose including JIT into PHP.
>>
>> https://wiki.php.net/rfc/jit
> 
> I don't see anywhere in this RFC how it would affect thigns that do
> sneaky things with internals, such as Xdebug. How is that going to be
> affected?
> 

I suppose Xdebug should work on non-JIT-ed versions of the functions.
Even JVM deoptimizes to bytecode when debugging.

Thanks. Dmitry.

>> 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.
> 
> I do not believe that something major like this should make it into any
> PHP 7.x release. Having it as experimental new feature in the master/PHP
> 8.0 branch makes the most sense to me.
> 
> cheers,
> Derick
> 


Re: [PHP-DEV] RFC Abolish Narrow Margins

2019-01-31 Thread Dmitry Stogov


On 1/31/19 7:23 PM, Joe Watkins wrote:
> Hi Zeev, Dmitry,
> 
> It is not my only concern, I'm grateful for the clarification whatever.
> 
> These are your actual words from the RFC:
> 
>  > This works, but this functionality is not supported on all libffi 
> platforms, it is not efficient and leaks resources by the end of 
> request. It's recommended to minimize the usage of PHP callbacks.

Do you understand what is PHP callback in context of FFI?
In the following example, it's used to override zend_write by PHP 
function, but FFI can't know when this callback is not used by C 
anymore, and keeps it until the end of request.

zend_write;
$zend->zend_write = function($str, $len) {
global $orig_zend_write;
$orig_zend_write("{\n\t", 3);
$ret = $orig_zend_write($str, $len);
$orig_zend_write("}\n", 2);
return $ret;
};
echo "Hello World!\n";
$zend->zend_write = $orig_zend_write;
?>

> To me, a foreign function interface where one side of the interface 
> sounds broken and inefficient, according to the author, is scary. I've 
> never worked with libffi, so don't know if that's normal ... but I think 
> you can understand my thoughts here.

There is the same issue with FFI for LuaJIT.
I'm not sure if Python CFFI supports callbacks.

> Aside from whatever technical issues I may have misinterpreted or 
> misidentified, these are not my main objections to it being merged.

I got it.

Thanks. Dmitry.

> 
> Cheers
> Joe
> 
> On Thu, 31 Jan 2019 at 17:20, Zeev Suraski  <mailto:z...@php.net>> wrote:
> 
> 
> 
> On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> The fact that FFI may leak, is because it uses "unmanaged
> memory" (like
> in real C). PHP reference counting and GC just can't handle all the
> cases. It's impossible to automatically know what to do with C
> pointer,
> when we get it from function or another structure. In this case
> programmer have to care about freeing the pointer themselves
> (like in C).
> 
> This obviously doesn't count as 'leaks'.  If it did, we could say
> that the Zend Extension API leaks, as it's completely up to the
> developer to handle memory management.
> 
> Joe - if that's your concern, I think it's fair to say it's
> invalid and you have nothing to worry about.
> 
> Zeev
> 


Re: [PHP-DEV] [RFC] JIT

2019-01-31 Thread Dmitry Stogov


On 1/31/19 7:01 PM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  <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.
> 
> 
> Thanks. Dmitry.
> 
> 
> This has been a long time on the horizon, nice to see this finally 
> moving forward :)
> 
> Here are some initial thoughts: I think that it's best to approach this 
> issue from a cost/benefit angle. The benefits of the JIT compiler are 
> roughly (and as already outlined in the RFC):
> 
>   * Significantly better performance for numerical code.
>   * Slightly better performance for "typical" PHP web application code.
>   * The potential to move more code from C to PHP, because PHP will now 
> be sufficiently fast.
> 
> However, there are also a number of costs, on which I'll expand in more 
> detail:
> 
> a) Maintenance: This is really my main concern. Right now there are 
> about 3-4 people who I would trust to carry out a non-trivial language 
> change, which will require touching the compiler, the virtual machine, 
> the optimizer and the persistence layer. Each of those components is 
> quite complex, in different ways. Some people who are comfortable with 
> doing VM changes will struggle with implementing optimizer changes.
> 
> Adding a JIT compiler exacerbates this issue further. Because this JIT 
> is dynasm based, the core JIT code is essentially written in raw x86 
> assembly. This will further limit the pool of people who will be able to 
> make non-trivial engine changes. Personally, I don't have any particular 
> familiarity with writing x86 assembly, so it will likely take a while to 
> get up to speed with this code.
> 
> b) Bugs and stability: I think that everyone is aware that the initial 
> PHP 7.3 release suffered from substantial stability issues, more than 
> new minor version releases tend to do. I think there are multiple 
> reasons for that (and we might want to start a conversation about our QA 
> processes in a separate thread), but one main contributing factor were 
> opcache optimizer bugs. Compiler optimizations are tricky and hard to 
> verify, and we often only learn about issues once the optimizer makes 
> contact with production codebases, which feature a much richer 
> collection of code patterns than our test suite. One can wonder whether 
> the relatively minor speedups we get from our optimization framework are 
> really worth having these stability issues...
> 
> Adding a JIT compiler adds a new dimension of stability issues. Next to 
> "simple" executor bugs, and optimizer bugs, we now get additional bugs 
> in the JIT. These are probably going to be hard to debug, as we'll have 
> to drop down from our usual C-level tooling, down to inspecting assembly.
> 
> c) Platform support: Having a JIT segregates platforms into two tiers: 
> Those that have JIT support and those that don't. While that is not a 
> problem per se, it does introduce some dangers. For example, if we 
> decide to more parts of our C code into PHP because PHP is fast enough 
> with a JIT, that will of course only be true for platforms that actually 
> have JIT support. I'm not terribly concerned about loosing out some 
> performance on MIPS, but we do need to make sure that all our main 
> platforms are supported (Windows is a must there, imho).

I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.

> d) Debugging: I'm not sure whether or not this is an issue (maybe the 
> RFC can clarify?), but I'm wondering if this will have an impact on 
> things like XDebug. Will it be possible to using XDebug to accurately 
> inspect variables at any point in time while the JIT is running? If not, 
> that would be a big tooling regression.

XDebug may work with JIT or opcache disabled.

> 
> I think those are the main points that come to mind right now...

Anyway, I'm mostly agree with all the points.

There are two options :)
- take the challenge and start developing JIT together
- forget about JIT, because we are afraid

Thanks. Dmitry.

> 
> Regards,
> Nikita


Re: [PHP-DEV] RFC Abolish Narrow Margins

2019-01-31 Thread Dmitry Stogov
Hi Joe,

On 1/31/19 6:56 PM, Joe Watkins wrote:
> Afternoon Zeev,
> 
>> I'll happily take your interpretation of it.  No hard feelings.
> 
> Thanks, you know I don't have another way of being :)
> 
> When I refer to "you", I really mean you and Dmitry, while you don't have a
> hive mind, you do act as one, or for one another in a lot of cases. If I'm
> wrong about that, I apologise.
> 
>> I would say that Dmitry has by far the best track record of fixing any
> outstanding issues
> 
> I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
> said it had leaks ... what am I supposed to think about that ? If someone
> does a patch for /Zend and it leaks or is suboptimal in any way, it does
> not land on Dmitry's say so, but it's okay for him to merge stuff with
> known defects ... I think the problem there is quite clear.

The fact that FFI may leak, is because it uses "unmanaged memory" (like 
in real C). PHP reference counting and GC just can't handle all the 
cases. It's impossible to automatically know what to do with C pointer, 
when we get it from function or another structure. In this case 
programmer have to care about freeing the pointer themselves (like in C).

This is all about the FFI leaks.

Thanks. Dmitry.

> 
>> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
> 
> So you want to say that for FFI to be used, it had to be included in
> php-src ? That's nonsense, the kind of people who are capable of using FFI
> are also capable of installing an extension. From my perspective it had no
> justification for being merged at all, but there were very good reasons to
> keep it out of php-src not least the slim majority on which it was merged.
> 
>> I actually agree with you that the fact it didn't clear a 2/3 vote, and
> with a hefty margin - is not very ideal.
> 
> So it sounds like we agree here, it was pushed into php-src on an
> unacceptable margin.
> 
>> I categorically disagree that it is an incomplete feature;  I presume
> you're saying this because it currently supports Linux x86/x64?
> 
> This sounds disingenuous to me, you are trying to make it sound ready
> before it actually is.
> 
>>   It's not unusual for complicated pieces of software to first be
> available for specific subsets of platforms, and than gradually be ported
> to others
> 
> That's true, but Windows is a core platform for PHP, if you haven't got
> Windows, you got nothing. I wouldn't make such a fuss about windows or
> fancy architectures, if I thought there was anyone around who could
> actually implement them, as far as I know there isn't and if they are
> unimportant to dmitry and yourself, then it won't get done.
> 
>> I think there were questionable decisions that happened long before
> FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
> for them specifically.
> 
> Check the date on the rfc, nothing is happening suddenly.
> 
>>   I'm not fine with rushing to hastily change the rules (while breaking
> the existing ones) to counter a specific RFC.
> 
> As I have already explained, I'm prompted to act because of a pattern of
> behaviour and decisions that I find questionable, and so do others ... and
> by your own admission, so do you ...
> 
> I should make clear that I think FFI is really cool although I haven't
> found time to play with it yet, and clearly I want us to have a JIT, and
> marvel at the achievement. I can't wait to start reading it (again) and
> trying to understand. This is not about one or two RFCs, but making simple
> changes to give us more confidence in the decisions we are all making, and
> it certainly isn't an attack on you or Dmitry, nothing of the sort ...
> 
> I think we don't really have anything to argue about, and to reiterate, I
> will be taking this RFC to vote.
> 
> Cheers
> Joe
> 
> 
> On Thu, 31 Jan 2019 at 16:13, Zeev Suraski  wrote:
> 
>>
>>
>> On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:
>>
>>> Afternoon Zeev,
>>>
>>> I'm going to use unambiguous and direct language to make sure my
>>> intentions
>>> and concerns are communicated clearly, you can either receive this as a
>>> personal attack, or as a contributor being direct, I would prefer the
>>> latter.
>>>
>>
>> I fail to see how in the way it was written it could not be taken as a
>> personal attack, but since you wrote it, I'll happily take your
>> interpretation of it.  No hard feelings.
>>
>>
>>> You pushed FFI into php-src on a simple majority
>>
>>
>> I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
>> but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
>> same person, nor do we have a hive mind...
>>
>>
>>> was
>>> incomplete (with leaks),
>>
>>
>> I would say that Dmitry has by far the best track record of fixing any
>> outstanding issues - not only with his code, but with the code of mostly
>> everyone else contributing to PHP, so if 

[PHP-DEV] Refactor zend_object_handlers API to pass zend_object* and zend_string* insted of zval(s)

2019-01-31 Thread Dmitry Stogov
Hi Nikita,


We already discussed this few months ago in context of PHP-7.4.

Please review the updated PR for master.


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


Thanks. Dmitry.


Re: [PHP-DEV] [RFC] JIT

2019-01-31 Thread Dmitry Stogov


On 1/31/19 1:15 PM, Albert Casademont wrote:
> Hi all,
> 
> This is fantastic news thank you! I was going to ask if JIT would also 
> work when Opcache is enabled with "opcache.file_cache_only".

Unfortunately, not yet, but we are planning to move opcache into PHP-8 
core and allow optimization and JIT without caching.

> Our use 
> case is a ReactPHP app that right now only has Opcache basically for the 
> optimizations and we do not use the standard shared memory portion. We 
> believe JIT could improve quite a lot these kinds of "long-running" 
> processes that can serve multiple requests per-process. Thanks a lot!

Better to try and provide feedback right now.
You can get sources and build PHP from the link in RFC.
https://github.com/zendtech/php-src/

Thanks. Dmitry.

> 
> Best,
> 
> 
> 
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  <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.
> 
> 
> Thanks. Dmitry.
> 


[PHP-DEV] [RFC] JIT

2019-01-31 Thread Dmitry Stogov
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] Old style constructors in PHP-8

2019-01-30 Thread Dmitry Stogov
Hi,


I've just noticed that Wordpress-4.1 on PHP master started silently produce 
different output.

The problem that PHP master started to ignore old-style constructors.

They were deprecated in PHP-7 and PHP produced the following warning


Deprecated: Methods with the same name as their class will not be constructors 
in a future version of PHP; ... has a deprecated constructor


PHP master doesn't produce any warnings and just constructs a class without 
constructor.

This silent behavior change may become a problem for porting legacy code to 
PHP-8,

May be, it makes sense to emit fatal error in case of old-style constructor.


Thanks. Dmitry.


Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

2018-12-24 Thread Dmitry Stogov


On 12/24/18 4:50 PM, Christoph M. Becker wrote:
> On 24.12.2018 at 08:38, Dmitry Stogov wrote:
> 
>> On 12/22/18 1:32 PM, Nikita Popov wrote:
>>
>>> My main concern here is that this is a very new extension and I think
>>> that apart from you barely anyone had a chance to actually implement
>>> something based on it and gain experience using the proposed API.
>>> Bundling an extension with PHP means that the API becomes frozen in time
>>> and it becomes very hard to change anything.
>>> I think that having FFI support is important, but I'm afraid that once
>>> we bundle this extension and it will see more usage, it will quickly
>>> turn out that the API needs to change to make it easier to use or
>>> accommodate more use-cases.
>>
>> The API almost completely repeats LuaJIT and Python CFFI (that are
>> stable). Something might need to be improved, of course, but only in
>> case the extension is going to be widely used.
> 
> If we are concerned about the API stability, we could mark the extension
> as experimental and exempt it from our usual BC guarantee, as suggested
> by Niklas[1].  On the other hand, if PHP 8 will be next after PHP 7.4,
> this may not even be necessary.

Right.

> 
>> The main reason, I like to have this in core - future integration with JIT.
> 
> It seems to me that JIT integration of FFI isn't the whole story, but
> rather an intermediate step to be able to offer built-in functionality
> written in PHP in the long run, which could be a huge enhancement.  Am I
> correct?

In current state FFI is more like a great toy. It allows to quickly 
prototype on top of binary interfaces, but the resulting performance is 
going to be poor, because of interpretation overhead.

However, LuaJIT proved that it's possible to integrate JIT and FFI and 
achieve almost C performance. This could open a real door for writing 
PHP extensions in PHP itslef.

> Anyhow, my main concerns regarding the proposal are that people could
> easily be led into thinking that FFI is *the* new way to interface with
> external code, rendering classic extensions obsolete, and that
> interfacing on the ABI level is even more error-prone than interfacing
> on the C API level.  Both concerns could be alleviated by good
> documentation, though.

Agree. FFI is dangerous, especially for programmers without C 
background. Without FFI they just can't make a lot of harm.
However, the proposal offers to enable FFI only for preloaded files (and 
CLI), by default.

Thanks. Dmitry.

> 
> [1] <https://externals.io/message/103613#103623>
> 


Re: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant Parameters

2018-12-24 Thread Dmitry Stogov
Hi Levi,


I made just few tests, to understand that the implementation is at least 
incomplete.

The warning message depends on class declaration order and may be emitted or 
not.


  1.  This test produces a warning (as RFC proposes)





2. But this test misses warning





- The patch is incompatible with opcache (crashes on Wordpress, Drupal, and 
probably any real-life app).

- the incompatibility with opcache, doesn't allow to check the performance 
implication of the patch

- the patch has merge conflicts and travis tests doesn't run.


Personally, I'm not against the proposal, but I'm definitely against this 
implementation.

Probably, it's better to cancel the voting and restart when the implementation 
is ready.


It's pity to see, that nobody tries the implementation but blindly vote...


Thanks. Dmitry.


From: Dmitry Stogov 
Sent: Friday, December 21, 2018 10:28:05 AM
To: Levi Morrison
Cc: internals
Subject: Re: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant 
Parameters



On 12/21/18 3:12 AM, Levi Morrison wrote:
> On Thu, Dec 20, 2018 at 3:35 PM Dmitry Stogov  wrote:
>>
>> Hi Levi,
>>
>>
>> It looks like the patch broke something related to opcache.
>>
>> It crashes at least on Wordpress and Drupal.
>>
>> The backtrace 
>> https://gist.github.com/dstogov/a2305381a5c9982cceca9e4e252d26c7 shows 
>> use-after-free in opcache (works fine with master).
>>
>> Inability to work with opcache, doesn't allow to check the performance 
>> impact.
>>
>>
>> It also broke few tests. Some crash. Some produce different warning/errors.
>>
>>
>> $ make test TESTS="Zend tests"
>>
>> ...
>>
>> =
>> FAILED TEST SUMMARY
>> -
>> ZE2 ArrayAccess and ArrayAccessReferenceProxy with references to main array 
>> [tests/classes/array_access_011.phpt]
>> Bug #21478 (Zend/zend_alloc.c :: shutdown_memory_manager produces segfault) 
>> [Zend/tests/bug21478.phpt]
>> Generator methods can yield by reference 
>> [Zend/tests/generators/generator_method_by_ref.phpt]
>> Testing to implement Serializable interface by traits 
>> [Zend/tests/traits/interface_003.phpt]
>> Handling of public fields with traits needs to have same semantics as with 
>> normal inheritance, however, we do add strict warnings since it is easier to 
>> run into something unexpeted with changing traits. 
>> [Zend/tests/traits/property009.phpt]
>> iterable type#004 - Parameter covariance 
>> [Zend/tests/type_declarations/iterable_004.phpt]
>> iterable type#005 - Return type covariance 
>> [Zend/tests/type_declarations/iterable_005.phpt]
>> =
>>
>> I'll try to play with patch and make a full code review on next week.
>>
>>
>> It would be great, if you fix opcache compatibility.
>>
>> If it can't be done in reasonable time, it's probably better to cancel 
>> voting and restart when ready.
>
> What OS and compiler are these on?

Linux (Fedora 28), GCC 8.2.1.

> How are you ensuring that opcache
> is on when these tests are run? I have not been experiencing these
> issues, so maybe I am not running it correctly. If I cannot reproduce
> them soon then I will agree to cancel the voting.

You should enable opcache in your php.ini

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.optimization_level=-1
opcache.protect_memory=1 ; this is for testing only


Memory corruption bugs may lead to crash or not because of "luck", but
it's possible to see them using valgrind.

$ make test TESTS="-m tests/classes/array_access_011.phpt"
$ cat tests/classes/array_access_011.mem

This shows almost the same backtrace, as I already published.
Looks like an incorrect reference-counting on some string.

>
> There are some known issues outside of Zend. Notably some internal
> classes do not have valid method signatures with regards to
> inheritance which this patch exposed. These need fixed regardless of
> this RFC and I have begun work on some of them (see
> https://github.com/php/php-src/pull/3686 for one example).

That PR looks fine.

There is also a problem that this PR has merge conflict with master and
travis doesn't run tests.

Thanks. Dmitry.


[PHP-DEV] Re: Changes to when OPcache initialises

2018-12-23 Thread Dmitry Stogov
Looks fine.


On 12/24/18 12:17 AM, Derick Rethans wrote:
> Hi,
> 
> VLD is not a zend extension, so gets loaded/initialised later anyway.
> And it seems your hint with post_startup works. I'd appreciate if you
> could have a look at my change though:
> 
> https://github.com/xdebug/xdebug/commit/3ef3c63ffc831426a45439dbf8b56b998f84d5b1
> 
> cheers,
> Derick
> 
> On Mon, 17 Dec 2018, Dmitry Stogov wrote:
> 
>> Hi Derick,
>>
>>
>> First, check why VLD works out of the box.
>>
>> At second, you may plug into post_startup hook to reassign zend_compile 
>> after opcache.
>>
>>
>> Thanks. Dmitry.
>>
>> ________
>> From: Derick Rethans 
>> Sent: Saturday, December 15, 2018 10:01:37 PM
>> To: Dmitry Stogov
>> Cc: Nikita Popov; PHP Developers Mailing List
>> Subject: Changes to when OPcache initialises
>>
>> Hi!
>>
>> I am working on making Xdebug work properly with PHP 7.3, and over the
>> last week I have been tearing my hair out as to why Xdebug's view of
>> opcodes was no longer showing the opcodes that OPcache had
>> modified/optimised. In PHP 7.2, the order in which you load Xdebug and
>> OPcache made a difference.
>>
>> OPcache optimises out line 6, which has dead code:
>>
>>1 >2
>>3 try
>>4 {
>>5 throw new Exception();
>>6 echo strlen( "Revenge is a dish best served cold.\n" );
>>7 }
>>8 catch(Exception $e)
>>9 {
>>   10 }
>>   11
>>   12 echo strlen( "The fire is always hotter on someone elses face." ), "\n";
>>   13 ?>
>>
>>
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.2.13/bin/php  
>> -n -dzend_extension=opcache.so  -d "zend_extension=xdebug.so" -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(4) {
>>[5] =>
>>int(1)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>>
>> [GIT: issue1598-no-code-coverage-with-opcache][PHP: 7.2.13  ]
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.2.13/bin/php  
>> -n  -d "zend_extension=xdebug.so" -dzend_extension=opcache.so -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(5) {
>>[5] =>
>>int(1)
>>[6] =>
>>int(-2)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>>
>> Where as with PHP 7.3.0, they both show the *unoptimised* version:
>>
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.3.0/bin/php  
>> -n -dzend_extension=opcache.so  -d "zend_extension=xdebug.so" -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(5) {
>>[5] =>
>>int(1)
>>[6] =>
>>int(-2)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>> [GIT: issue1598-no-code-coverage-with-opcache][PHP: 7.2.13  ]
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.3.0/bin/php  
>> -n  -d "zend_extension=xdebug.so" -dzend_extension=opcache.so -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(5) {
>>[5] =>
>>int(1)
>>[6] =>
>>int(-2)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[

[PHP-DEV] Re: Changes to Traits in master/PHP 7.4

2018-12-23 Thread Dmitry Stogov
Done. Thanks for noticing this.

On 12/24/18 12:24 AM, Derick Rethans wrote:
> Hi Dmitry,
> 
> You removed ADD_TRAIT and BIND_TRAITS in
> https://github.com/php/php-src/commit/67397970b25d03254f000c36a73204720475b324
> — could you please add that to UPGRADING.INTERNALS?
> 
> cheers,
> Derick
> 


Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

2018-12-23 Thread Dmitry Stogov


On 12/22/18 1:32 PM, Nikita Popov wrote:
> On Thu, Dec 20, 2018 at 4:13 PM Dmitry Stogov  <mailto:dmi...@zend.com>> wrote:
> 
> Hi internals,
> 
> 
> The FFI RFC is turned into voting state.
> 
> 
> https://wiki.php.net/rfc/ffi
> 
> 
> There were very few minor changes since the initial proposal, e.g.
> renaming FFI:array_type() into FFI::arrayType()
> 
> 
> Thanks. Dmitry.
> 
> 
> My main concern here is that this is a very new extension and I think 
> that apart from you barely anyone had a chance to actually implement 
> something based on it and gain experience using the proposed API. 
> Bundling an extension with PHP means that the API becomes frozen in time 
> and it becomes very hard to change anything.
> I think that having FFI support is important, but I'm afraid that once 
> we bundle this extension and it will see more usage, it will quickly 
> turn out that the API needs to change to make it easier to use or 
> accommodate more use-cases.
> 
> My other concern is platform support. FFI is by nature a rather platform 
> dependent. The RFC says that the extension is currently tested on Linux 
> and Windows. It would be great if someone using such a system can 
> confirm whether it also works on OSX and FreeBSD, so we at least have 
> coverage of the major platforms.
> 


The API almost completely repeats LuaJIT and Python CFFI (that are 
stable). Something might need to be improved, of course, but only in 
case the extension is going to be widely used.

The main reason, I like to have this in core - future integration with JIT.

Thanks. Dmitry.

> Nikita


Re: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant Parameters

2018-12-20 Thread Dmitry Stogov


On 12/21/18 3:12 AM, Levi Morrison wrote:
> On Thu, Dec 20, 2018 at 3:35 PM Dmitry Stogov  wrote:
>>
>> Hi Levi,
>>
>>
>> It looks like the patch broke something related to opcache.
>>
>> It crashes at least on Wordpress and Drupal.
>>
>> The backtrace 
>> https://gist.github.com/dstogov/a2305381a5c9982cceca9e4e252d26c7 shows 
>> use-after-free in opcache (works fine with master).
>>
>> Inability to work with opcache, doesn't allow to check the performance 
>> impact.
>>
>>
>> It also broke few tests. Some crash. Some produce different warning/errors.
>>
>>
>> $ make test TESTS="Zend tests"
>>
>> ...
>>
>> =
>> FAILED TEST SUMMARY
>> -
>> ZE2 ArrayAccess and ArrayAccessReferenceProxy with references to main array 
>> [tests/classes/array_access_011.phpt]
>> Bug #21478 (Zend/zend_alloc.c :: shutdown_memory_manager produces segfault) 
>> [Zend/tests/bug21478.phpt]
>> Generator methods can yield by reference 
>> [Zend/tests/generators/generator_method_by_ref.phpt]
>> Testing to implement Serializable interface by traits 
>> [Zend/tests/traits/interface_003.phpt]
>> Handling of public fields with traits needs to have same semantics as with 
>> normal inheritance, however, we do add strict warnings since it is easier to 
>> run into something unexpeted with changing traits. 
>> [Zend/tests/traits/property009.phpt]
>> iterable type#004 - Parameter covariance 
>> [Zend/tests/type_declarations/iterable_004.phpt]
>> iterable type#005 - Return type covariance 
>> [Zend/tests/type_declarations/iterable_005.phpt]
>> =
>>
>> I'll try to play with patch and make a full code review on next week.
>>
>>
>> It would be great, if you fix opcache compatibility.
>>
>> If it can't be done in reasonable time, it's probably better to cancel 
>> voting and restart when ready.
> 
> What OS and compiler are these on?

Linux (Fedora 28), GCC 8.2.1.

> How are you ensuring that opcache
> is on when these tests are run? I have not been experiencing these
> issues, so maybe I am not running it correctly. If I cannot reproduce
> them soon then I will agree to cancel the voting.

You should enable opcache in your php.ini

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.optimization_level=-1
opcache.protect_memory=1 ; this is for testing only


Memory corruption bugs may lead to crash or not because of "luck", but 
it's possible to see them using valgrind.

$ make test TESTS="-m tests/classes/array_access_011.phpt"
$ cat tests/classes/array_access_011.mem

This shows almost the same backtrace, as I already published.
Looks like an incorrect reference-counting on some string.

> 
> There are some known issues outside of Zend. Notably some internal
> classes do not have valid method signatures with regards to
> inheritance which this patch exposed. These need fixed regardless of
> this RFC and I have begun work on some of them (see
> https://github.com/php/php-src/pull/3686 for one example).

That PR looks fine.

There is also a problem that this PR has merge conflict with master and 
travis doesn't run tests.

Thanks. Dmitry.


Re: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant Parameters

2018-12-20 Thread Dmitry Stogov
Hi Levi,


It looks like the patch broke something related to opcache.

It crashes at least on Wordpress and Drupal.

The backtrace https://gist.github.com/dstogov/a2305381a5c9982cceca9e4e252d26c7 
shows use-after-free in opcache (works fine with master).

Inability to work with opcache, doesn't allow to check the performance impact.


It also broke few tests. Some crash. Some produce different warning/errors.


$ make test TESTS="Zend tests"

...

=
FAILED TEST SUMMARY
-
ZE2 ArrayAccess and ArrayAccessReferenceProxy with references to main array 
[tests/classes/array_access_011.phpt]
Bug #21478 (Zend/zend_alloc.c :: shutdown_memory_manager produces segfault) 
[Zend/tests/bug21478.phpt]
Generator methods can yield by reference 
[Zend/tests/generators/generator_method_by_ref.phpt]
Testing to implement Serializable interface by traits 
[Zend/tests/traits/interface_003.phpt]
Handling of public fields with traits needs to have same semantics as with 
normal inheritance, however, we do add strict warnings since it is easier to 
run into something unexpeted with changing traits. 
[Zend/tests/traits/property009.phpt]
iterable type#004 - Parameter covariance 
[Zend/tests/type_declarations/iterable_004.phpt]
iterable type#005 - Return type covariance 
[Zend/tests/type_declarations/iterable_005.phpt]
=


I'll try to play with patch and make a full code review on next week.


It would be great, if you fix opcache compatibility.

If it can't be done in reasonable time, it's probably better to cancel voting 
and restart when ready.


Thanks. Dmitry.


____
From: Dmitry Stogov 
Sent: Thursday, December 20, 2018 6:26:10 PM
To: Levi Morrison; internals
Subject: Re: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant 
Parameters

Hi Levi,


Please, create a Pull Request, to keep inline comments on github.


Thanks. Dmitry.


From: Levi Morrison 
Sent: Thursday, December 20, 2018 2:10:57 AM
To: internals
Subject: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant Parameters

Thank you for the feedback and discussion on the [Covariant Returns
and Contravariant Parameters RFC][1].

I have opened [voting on this RFC][2]. Given that this is a common
time for holidays for many people around the world it will be open
until at least January 2nd. Happy holidays!

  [1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
  [2]: 
https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#voting

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



Re: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant Parameters

2018-12-20 Thread Dmitry Stogov
Hi Levi,


Please, create a Pull Request, to keep inline comments on github.


Thanks. Dmitry.


From: Levi Morrison 
Sent: Thursday, December 20, 2018 2:10:57 AM
To: internals
Subject: [PHP-DEV] [RFC][Vote] Covariant Returns and Contravariant Parameters

Thank you for the feedback and discussion on the [Covariant Returns
and Contravariant Parameters RFC][1].

I have opened [voting on this RFC][2]. Given that this is a common
time for holidays for many people around the world it will be open
until at least January 2nd. Happy holidays!

  [1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
  [2]: 
https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#voting

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



[PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

2018-12-20 Thread Dmitry Stogov
Hi internals,


The FFI RFC is turned into voting state.


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


There were very few minor changes since the initial proposal, e.g. renaming 
FFI:array_type() into FFI::arrayType()


Thanks. Dmitry.



  1   2   3   4   5   6   7   8   9   10   >