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

> No problem, I can change the defaults but remove the fatal error if > jit=non-zero and jit_buffer_size=0, can I still turn it into a warning > though? > I think we don't need the warning. It's clear that JIT won't work with "opcache.jit_buffer_size=0" in php.ini. Thanks. Dmitry.

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

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

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

if someone sees any critical implementation issues. Thanks. Dmitry. On Thu, Oct 5, 2023 at 10:52 PM Dmitry Stogov wrote: > Hi internals, > > The vote on "A new JIT implementation based on IR Framework" RFC is > started. > > https://wiki.php.net/rfc/jit-ir > > Thanks. Dmitry. >

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

On Tue, Oct 17, 2023 at 8:46 PM Daniil Gentili wrote: > Hello, > > I would like to submit an RFC and PR to change a few INI defaults for > opcache, changing how JIT is disabled by default. > > Currently, JIT is disabled by default using the > |opcache.jit_buffer_size=0| default, instead of

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

On Fri, Oct 6, 2023 at 10:52 PM Levi Morrison wrote: > On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov > wrote: > > > > Hi internals, > > > > The vote on "A new JIT implementation based on IR Framework" RFC is > started. > > > > https://w

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

On Thu, Oct 5, 2023 at 11:07 PM Tim Düsterhus wrote: > Hi > > On 10/5/23 21:52, Dmitry Stogov wrote: > > The vote on "A new JIT implementation based on IR Framework" RFC is > started. > > > > https://wiki.php.net/rfc/jit-ir > > One small note

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

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

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

, Sep 21, 2023 at 11:26 AM Dmitry Stogov wrote: > Hi Internals, > > After all the Poll Request discussions (see > https://github.com/php/php-src/pull/12079), code-reviews and internal > discussions with core developers we decided to move this through the RFC > process. > > Th

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

Hi Deleu, On Thu, Sep 21, 2023 at 12:31 PM Deleu wrote: > > > On Thu, Sep 21, 2023 at 6:13 AM Tim Düsterhus wrote: > >> Hi >> >> On 9/21/23 10:26, Dmitry Stogov wrote: >> My understanding is that even if the new JIT might not (yet) be better >> than t

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

Hi Sebastian, On Thu, Sep 21, 2023 at 12:22 PM Sebastian Bergmann wrote: > Am 21.09.2023 um 11:13 schrieb Tim Düsterhus: > > Thank you. I find it important to follow the formal process, even if > many > > folks are not able to make a meaningful decision due to the lack of > > knowledge about

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

Hi Tim. On Thu, Sep 21, 2023 at 12:13 PM Tim Düsterhus wrote: > Hi > > On 9/21/23 10:26, Dmitry Stogov wrote: > > After all the Poll Request discussions (see > > https://github.com/php/php-src/pull/12079), code-reviews and internal > > discussions with core de

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

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

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

On Sat, Sep 16, 2023 at 12:46 PM Hans Henrik Bergan wrote: > I think the submodule approach is fine, but maybe it should be moved from > Dmitry's gh to php-src gh, or maybe it's own dedicated group, to reduce the > bus factor (how much work needs to be done if Dmitry is hit by a bus~) > ``git

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

On Sat, Sep 16, 2023 at 1:22 AM Tim Düsterhus wrote: > Hi > > On 9/15/23 17:50, Ben Ramsey wrote: > > Additionally, despite the use of a Git submodule complicating things for > > "everyone else," it provides a clear dependency and development > > boundary, avoiding situations where the php-src

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

On Mon, Sep 18, 2023 at 8:01 AM Pierre Joye wrote: > Great work! This is a massive jump for PHP. Thank you :) > > I don't have much concerns about the license etc as the ZE is already > under Zend the ZE license (never updated since Perforce acquired them, > tho'): > >

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

Hi Ben, On Fri, Sep 15, 2023 at 6:50 PM Ben Ramsey wrote: > On 9/15/23 09:35, Derick Rethans wrote: > > > I understand that working on an RFC for such a complex issue is going to > > take time, but that also gives to opportunity to pair with somebody, > > who, while writing it, will also learn

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

Hi Derick, On Fri, Sep 15, 2023 at 5:35 PM Derick Rethans wrote: > I think this is great work. It looks like the new JIT-IR approach is > more suitable. I have however concerns with a few things here. > > This is a lot of new code, that very few other people understand in > great detail. > > I

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

On Fri, Sep 15, 2023 at 4:03 PM Juliette Reinders Folmer < php-internals_nos...@adviesenzo.nl> wrote: > If merged to `master`, will that automatically mean that the next > version of PHP will be PHP 9.0 ? > > If so, would that warrant a separate discussion ? (whether there should > still be a

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

problems, I'm going to remove the old JIT implementation and make a PHP-JIT code-cleanup pass. Thanks. Dmitry. On Mon, Sep 11, 2023 at 12:28 PM Dmitry Stogov wrote: > Hi internals, > > I'm glad to present a new JIT engine that is going to be used in the next > major PHP versi

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

Hi internals, I'm glad to present a new JIT engine that is going to be used in the next major PHP version. Now it's a real optimizing compiler with Intermediate Representation similar to Java HotSpot server compiler. It makes a base for future improvements and eliminates many low-level details

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

On Wed, Jul 5, 2023 at 1:15 AM Ilija Tovilo wrote: > Hi everyone > > I recently discovered some unfortunate behavior of the coalesce > assignment operator (??=) in combination with function calls. Here's > the TL;DR: > > foo()['bar'] ??= 42; > > Currently, this code calls foo() twice. This seems

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

On Wed, Mar 1, 2023 at 11:34 AM Niels Dossche wrote: > On 3/1/23 08:42, Dmitry Stogov wrote: > > On Wed, Mar 1, 2023 at 8:37 AM Max Kellermann wrote: > > > >> On 2023/02/28 23:33, Max Kellermann wrote: > >>>> Include cleanups RFC was rejected.

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

On Wed, Mar 1, 2023 at 8:37 AM Max Kellermann wrote: > On 2023/02/28 23:33, Max Kellermann wrote: > > > Include cleanups RFC was rejected. > > > No refactoring RFC was presented. > > > A lot of changes that affect all core contributors are committed into > > > master. > > > > Do you mean to

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

On Wed, Mar 1, 2023 at 1:21 AM Max Kellermann wrote: > On 2023/02/28 22:31, Dmitry Stogov wrote: > > > https://github.com/php/php-src/commit/0270a1e54c0285fa3c89ee2b0120073ef57ab5fa > > This kind of change was favored by a supermajority. > > You argue that this supermaj

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

On Wed, Mar 1, 2023 at 12:04 AM Max Kellermann wrote: > On 2023/02/28 21:16, Dmitry Stogov wrote: > > Recently we voted for inluce cleanup RFC > > https://wiki.php.net/rfc/include_cleanup and it was declined. > > Despite that a series of code refactoring commits f

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

commit/42577c6b6b7577c57c161ee4a74cb193382bf1e0 https://github.com/php/php-src/commit/c7637ed1c03f556c6fb65884cfc5bfea4920b1c7 https://github.com/php/php-src/commit/371ae12d890f1887f79b7e2a32f808b4595e5f60 Thanks. Dmitry. > > On Tue, Feb 28, 2023, 3:17 PM Dmitry Stogov > wrote: > >> Hi

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

Hi @internals, I have to say that we came to a serious conflict. Recently we voted for inluce cleanup RFC https://wiki.php.net/rfc/include_cleanup and it was declined. Despite that a series of code refactoring commits from Max were silently merged into the master. As this is a violation of the

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

On Mon, Feb 13, 2023 at 12:51 PM Max Kellermann wrote: > On 2023/02/13 10:28, Dmitry Stogov wrote: > > It's OK when commits are reverted. > > You are working in a common repository, and if your commits become > stoppers > > for others they have to be reverted. >

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

On Mon, Feb 13, 2023 at 11:35 AM Max Kellermann wrote: > On 2023/02/13 01:58, "G. P. B." wrote: > > We have had completely broken builds for longer days due to some other > > random changes, and we didn't revert them but fixed them as a follow-up. > > We still, for over 6 months now, have a

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

Here are my comments about the last PR https://github.com/php/php-src/pull/10345 Max asked to repost them in this thread: In my opinion this should not be accepted. Despite the intention is good, this huge patch doesn't improve anything but adds new questions. - It introduces new include

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

elp clean up this mess that had accumulated over two > decades. > > All PRs were welcomed by different reviewers and were merged; there > was just one minor criticism by Dmitry Stogov who thought the code > comments explaining many non-obvious #includes should be removed: > > https:

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

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 co

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.

Re: [PHP-DEV] VM kinds

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

Re: [PHP-DEV] timelib performance fix

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

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

[PHP-DEV] FFI Type Reflection API

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

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

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

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

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

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

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

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

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

[PHP-DEV] Re: timelib inefficiency

orld"). 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 inl

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

ou 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, > > &g

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,

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

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_

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

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

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

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

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

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

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

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

[PHP-DEV] Re: timelib inefficiency

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

[PHP-DEV] Re: timelib inefficiency

se, 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, &g

[PHP-DEV] timelib inefficiency

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

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

+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

Re: [PHP-DEV] Inheritance Cache

ime? > > 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

[PHP-DEV] Inheritance Cache

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

[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

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:

Re: [PHP-DEV] ZEND_ENGINE_4

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

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

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

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

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

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

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

[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

t; 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 > &g

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

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,

Re: [PHP-DEV] PHP 8.0 branch cut

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

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

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 >

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

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

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

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 >

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

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

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

andard 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 a

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

rence >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 Subje

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

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

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:

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

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

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

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 >

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

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

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

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

[PHP-DEV] Re: PHP 8 Preview Releases

. 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

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

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

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

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

ut 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

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

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

Re: [PHP-DEV] [RFC] JIT

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 &

Re: [PHP-DEV] [RFC] JIT

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, > -Origi

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

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

Re: [PHP-DEV] [RFC] JIT

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

Re: [PHP-DEV] [RFC] JIT

. 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

Re: [PHP-DEV] [RFC] JIT

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

Re: [PHP-DEV] [RFC] JIT

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

[PHP-DEV] Re: ZTS improvement idea

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-DEV] Re: ZTS improvement idea

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) ;

Re: [PHP-DEV] [RFC] JIT

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

Re: [PHP-DEV] [RFC] JIT

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 (-dopcac

Re: [PHP-DEV] [RFC] 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:/

[PHP-DEV] Re: ZTS improvement idea

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

[PHP-DEV] Re: ZTS improvement idea

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 cam

[PHP-DEV] 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 This is not an RFC and I'm not sure, if I like to implement TSRM changes myself now. Comments are welcome.

Re: [PHP-DEV] RFC Abolish Narrow Margins

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, Ja

Re: [PHP-DEV] RFC Abolish Narrow Margins

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

Re: [PHP-DEV] [RFC] JIT

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 <

Re: [PHP-DEV] [RFC] JIT

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;

Re: [PHP-DEV] [RFC] JIT

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, 201

  1   2   3   4   5   6   7   8   9   10   >