[PHP-DEV] RE: ZTS improvement idea

[Anatol Belski]

Hi Dmitry,

> > 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.
> 
Perhaps an idea for this could be to generate a special function for every 
extension to be exported, like get_module_globals_size(). It could be probably 
seamlessly integrated into ZEND_DECLARE_MODULE_GLOBALS(), so require no change 
to the existing code. Then on module load we could realloc() the flattened 
structure on demand. Still it'd be on heap, but it would be a contiguous chunk 
of memory.


> > 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).
> 
Yeah, gotcha. The very core globals should be easy to "prefill" for the 
flattened structure as the sizes are known at the compile time. All the others 
could be appended to them, perhaps the way I've suggested above or another if a 
better one is found.

Thanks

Anatol


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

[PHP-DEV] RE: ZTS improvement idea

[Anatol Belski]

> -Original Message-
> From: Dmitry Stogov 
> Sent: Thursday, February 14, 2019 11:21 PM
> To: Anatol Belski ; Nikita Popov 
> Cc: Joe Watkins ; Bob Weinand ;
> Nikita Popov ; z...@php.net; PHP internals
> 
> Subject: 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.net)
> >> ; z...@php.net; PHP internals 
> >> Subject: Re: ZTS improvement idea
> >>
> >> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  >>  > 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.
> 
Exactly. Plus, it might introduce issues with C++ compatibility.

Thanks

Anatol

[PHP-DEV] Re: Parallelised run-tests.php (patch)

[Andrea Faulds]

Hi everyone.

I've rebased this patch again: https://github.com/php/php-src/pull/3838

I guess this can serve as a reminder this exists and can be discussed.

Thanks!

Andrea Faulds wrote:

Hi there,

Do you spend HOURS every day AGONISING over how long run-tests.php takes 
to complete?


Have you long since ABANDONED every test directory besides Zend/tests?

Does it feel like your eight CPU cores are pointlessly WASTED by 
single-threaded PHP test execution?


Are you SADDENED every day at how high-quality the run-tests.php code 
is, DREAMING of an even worse mess?


Then I've got just the trick for you!

…*ahem*. Okay, enough terrible salesmanship. I felt like parallelising 
run-tests.php, so I did it. If you give it the flag -jX, it'll spawn X 
worker processes and throw batches at tests at them, and those worker 
processes will send back the results of tests for the parent process to 
display and collate. To avoid potential problems with tests that step on 
eachother's toes (i.e. access the same file or port or whatever), it 
gives each worker a particular directory of tests and it then executes 
those in parallel. Obviously, this means things aren't as parallel as 
they could be for very large test directories (looking at you, 
Zend/tests/…), though that's a solvable problem. :) Per a suggestion by 
Rasmus in an earlier thread, the parent hands out large directories to 
children first to reduce the time spent on children occupied with huge 
directories.


And what a difference it makes. On my Ubuntu 16.04 VirtualBox VM running 
inside Windows 10 Pro x64 on my Ryzen 1700 8-core 16-thread PC, here's 
vanilla run-tests.php against master on a --disable-all build:


=
TEST RESULT SUMMARY
-
Exts skipped    :   68
Exts tested :    7
-

Number of tests : 15613  8481
Tests skipped   : 7132 ( 45.7%) 
Tests warned    :    0 (  0.0%) (  0.0%)
Tests failed    :   30 (  0.2%) (  0.4%)
Expected fail   :   31 (  0.2%) (  0.4%)
Tests passed    : 8420 ( 53.9%) ( 99.3%)
-
Time taken  :  317 seconds
=

And here's run-tests.php -j16:

=
TEST RESULT SUMMARY
-
Exts skipped    :   68
Exts tested :    7
-

Number of tests : 15613  8481
Tests skipped   : 7132 ( 45.7%) 
Tests warned    :    0 (  0.0%) (  0.0%)
Tests failed    :   35 (  0.2%) (  0.4%)
Expected fail   :   31 (  0.2%) (  0.4%)
Tests passed    : 8415 ( 53.9%) ( 99.2%)
-
Time taken  :   80 seconds
=

That's about a quarter of the single-threaded time. It could get even 
better still if there were more test directories to work with; currently 
the number of alive workers declines as the test run goes on, because 
all the small directories get finished quickly and you're left waiting 
on the Zend/tests-like behemoths. One idea might be to add some sort of 
special file you could add to a directory which tells run-tests.php that 
it is safe to parallelise, in which case it would break it into chunks 
at runtime for you. Though I don't think we should have huge numbers of 
files in a single directory anyway, if possible.


Okay, but what's the catch? Well, the code isn't the most… elegant 
thing. I did make run-tests.php faster, but I didn't refactor it to be 
less of a global-variables-dependant mess than it is at present, except 
for moving all the top-level code into a single function for the sake of 
my own sanity. Therefore, the worker child processes get their own copy 
of the global state to initialise them. It's a bit hacky, but this is 
basically what UNIX fork() does, so maybe I shouldn't feel so bad. ;) On 
the other hand, the remainder of the design is quite elegant! It's all 
clean message-passing over STDIN and STDOUT.


This isn't fully tested yet. I haven't actually investigated those 5 
test failures, and my implementation probably breaks some run-tests.php 
features right now. I also haven't bothered to try this on a non 
--disable-all build yet. That said, I'm impressed how well it actually 
works right now and how effectively it tolerates errors. The child 
processes will even happily kill themselves if the parent does.


The code is here:

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

Happy Halloween.



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

Re: [PHP-DEV] [RFC] JIT

[Larry Garfield]

On Friday, February 15, 2019 3:36:40 AM CST Dmitry Stogov wrote:
> Just two things.
> 
> I definitely don't think, I "just made it 100x more complicated".
> I hate complication, and trying to make things simpler and more 
> efficient. This, sometime, involves new more or less isolated subsystems 
> like optimizer and now JIT. Of course, they look complex, if you are not 
> experienced in these areas. But PHP core may work without them.
> 
> Nobody will port their complex applications to PHP-8 preview, just to 
> try JIT. Having this possibility in PHP-7.4 would involve broader auditory.
> 
> Thanks. Dmitry.

Perhaps I missed this part, but is "port to PHP 8-preview" or "port to JIT" 
even a thing?  Presumably, just like with 7.0, any reasonably well-behaved 
application would be able to run without modification or with only minor 
modification on 8.0, no?

I mean, if someone wanted to try out their massive application to see if the 
JIT helped it, why would it be more work than (psuedocode):

git clone myapp.git
cd myapp
docker run php8-preview
*open web browser*

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] bugs.php.net problems?

[Bishop Bettini]

On Mon, Feb 11, 2019 at 1:04 AM Rasmus Lerdorf  wrote:

> On Sat, Feb 9, 2019 at 4:17 PM Ben Ramsey  wrote:
>
> > > On Feb 9, 2019, at 18:15, Stanislav Malyshev 
> > wrote:
> > >
> > > Hi!
> > >
> > > I am trying to access bugs.php.net and I am getting timeouts all the
> > > time today (TLS handshake passes, but no content is delivered). Seems
> to
> > > be something wrong with the site? Could somebody check it?
> >
> >
> > I’ve been experiencing the same thing today and yesterday. Traceroute and
> > ping returns fine, but anything over port 443 is very slow and times out
> > sometimes. At other times, the website loads fast.
> >
>
> Are you still seeing this? It is a Digital Ocean VM in NYC1 and I don't see
> anything odd aboout it. Are you hitting it over ipv4 or ipv6?
>

I'm experiencing the same symptoms Stas reported, starting circa 1452 UTC
2018-02-15. I've tried a variety of networks (hard-line IPv4, public AP
IPv6, wireless hotspot IPv6) and all timeout.

Re: [PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?

[BohwaZ/PHP]

Thanks Christoph!

Just to be clear, this patch doesn't prevent security issues if you 
don't update your SQLite3 library, it just implements a new option 
available in newer SQLite versions which will prevent arbitrary changes 
to the internals of a SQLite database only if you SQLite3 library is 
3.26+. Changing the internals of a SQLite database is something that 
should be quite rare in the real world I think.


This addresses potential security issues for PHP applications allowing 
end-users to run arbitrary SQL queries.


But please note that if your application does allow end-users to run 
arbitrary SQL queries, I advise that you limit them to read-only by 
either:


* opening the database as readonly (available in PDO since PHP 7.3: use 
open attribute: PDO::SQLITE_ATTR_OPEN_FLAGS => PDO::SQLITE_READONLY)
* using the SQLite3Stmt::readOnly method (will tell you if a prepared 
statement will write to the database)

* or using the equivalent for PDO:

$st = $pdo->prepare('SELECT * FROM table;');
var_dump($st->getAttribute(PDO::SQLITE_ATTR_READONLY_STATEMENT));

This last one should be available in PHP 7.4 I hope? See 
https://github.com/php/php-src/pull/2760


Both PDO features are currently undocumented but it's on my TODO list as 
well.


If your users are performing custom SELECT queries, this is the best 
thing to do.


I am now working on bringing support for a userland custom callback to 
the SQLite3 authorizer API, this will allow PHP code to restrict access 
to specific tables, columns and operations, that should also improve 
security in the future.


As a side note, although my time is quite limited, I have worked for the 
last two years to improve features support and security of the SQLite3 
extension and try to match features of the SQLite3 extension in PDO as 
well.


I have to give a warm thank you to Christoph and everyone else who 
helped me in this :)
And if anyone is interested in helping me improve SQLite support in PHP 
you are more than welcome :)


Cheers.

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

[PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?

[Christoph M. Becker]

Hi!

You may have heard about the so called “Magellan vulnerabilities”[1]
which potentially affect scripts which allow untrusted users to execute
almost arbitrary SQL queries.  BohwaZ provided a pull request[2] which
introduces an ini setting which enables defenses built-in to SQLite ≥
3.26.0 against the corruption of tables via SQL.

In my opinion, adding this ini setting to PHP-7.4 is a no brainer, but I
suggest that we backport it to PHP-7.2 as well.

And likely we should offer something of this kind for PDO as well.  Not
sure if a driver specific ini setting would be suitable.  Suggestions
welcome!

Thoughts?

[1] 
[2] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: ZTS improvement idea

[Rowan Collins]

On Fri, 15 Feb 2019 at 07:26, Benjamin Eberlei  wrote:

> This is like the 80% use-case of threading, Multiple HTTP requests, multiple 
> long running SQL queries. An API like parallel would allow each and everyone 
> of us to make controllers faster today without a large effort.
>
>
I think an expanded example would better demonstrate the power of this.
Consider a search API that aggregates other search APIs; for each API, it
will need to do several steps:

- Look up code mappings in a DB to convert input into format needed by this
API
- Perform an auth request to get a fresh token
- Send the search API call
- Look up more code mappings to convert the response
- Post-process results into a standard form

The challenge is to call as many APIs as possible at once, and get the
results to the user. The slow parts of this are mostly I/O bound, but to
take advantage of async I/O you need to rewrite not just the I/O parts but
the entire process to use some async framework. Maybe there's even parts
that are CPU heavy in between the requests - a complex cryptographic
algorithm, for instance - that async I/O wouldn't help with at all, but
which could happen on separate cores when load was low.

It would be absolutely amazing if you could use something like Joe's new
parallel extension to handle this workload: run the handling of each API as
a thread, and leave the code inside them entirely unchanged.

I realise it's probably not as simple as that in practice, but to me, the
ability to adapt existing code is a huge benefit of a straightforward
parallel/thread/worker API over one based explicitly on async I/O.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] JIT

[Arvids Godjuks]

пт, 15 февр. 2019 г. в 13:05, Benjamin Eberlei :

>
>
> On Fri, Feb 15, 2019 at 10:37 AM Dmitry Stogov  wrote:
>
>> Just two things.
>>
>> I definitely don't think, I "just made it 100x more complicated".
>> I hate complication, and trying to make things simpler and more
>> efficient. This, sometime, involves new more or less isolated subsystems
>> like optimizer and now JIT. Of course, they look complex, if you are not
>> experienced in these areas. But PHP core may work without them.
>>
>> Nobody will port their complex applications to PHP-8 preview, just to
>> try JIT. Having this possibility in PHP-7.4 would involve broader
>> auditory.
>>
>>
> The majority of people uses PHP from pre compiled sources (99%+),
>
> With 7.4 there are just two options:
>
> 1. we add jit as a flag called --enable-experimental-jit - which no
> distribution will do, and you don't have additional exposure with this
> approach.
> 2. or you add it as --enable-jit, and distributions might assume its
> stable and ship it by default, causing potential stability problems.
>
> Both cases are not preferrable to 8.0 master snapshots in my opinion.
>

Well, for production you probably are not gonna use JIT anyway with 7.4, so
not really an issue about distributions. But we have docker, so if there is
a docker image with the JIT - we can use that for testing and local
development.


-- 
Arvīds Godjuks

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

Re: [PHP-DEV] Re: ZTS improvement idea

[Pierre Joye]

Hi Benjamin,

On Fri, Feb 15, 2019, 2:26 PM Benjamin Eberlei 
> Async.io is used for scalability In languages with entirely different
> architectures than PHP.
>
> Node.js isn't well suited to monolithic applications such as Wordpress,
> Magento and the fast amount of applicatoins that people are building in PHP
> right now.


> One needs some supporting microservices here and there (to do websockets,
> high throughput work with lots of I/O, small daemons, ...) which right now
> people are using Go or Node.js for next to PHP, swoole or react-php.
>


This is like the 80% use-case of threading, Multiple HTTP requests,
> multiple long running SQL queries. An API like parallel would allow
> each and everyone of us to make controllers faster today without a
> large effort.
>
> Swoole is nice, but it will never be the 80% use-case for PHP users.


All async I/O APIs heavily lean on node.js APIs, which is an entirely
> different paradigm to program on and not PHP. Plus you have to rewrite
> all libraries to support this, instead of being able to re-use the
> libraries and style that PHP has championed for all this time.
>

I think you are right in your analysis. However I fail to see where you are
heading to.

It is the same as when couchbase or other Mongodb drivers were created, or
OO features.

100% of the existing code base were not suited for them. Still, these
features open new doors for php as a leading web language.

The same applies to async io and to some extend parallelism (in different
area than web servers tho'). And yes, async requires much more efforts
(overall applications architecture) to port libraries or application to
fully use them and benefit from async IO.

I am convinced PHP will be able to have these features and remain a leader
for a few more years.


PS: I will still use node, go or Python as well as always ;-)

best,
Pierre

>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Just two things.

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more 
efficient. This, sometime, involves new more or less isolated subsystems 
like optimizer and now JIT. Of course, they look complex, if you are not 
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to 
try JIT. Having this possibility in PHP-7.4 would involve broader auditory.

Thanks. Dmitry.

On 2/15/19 11:56 AM, Joe Watkins wrote:
> Morning Dmitry,
> 
>  > I told, I'm not going to do any active JIT development at this point.
>  > Why to waste time, if it's not going to be accepted...
> 
> At this point, *nobody* can imagine that PHP 8 will not have a JIT, 
> there is no sense in saying or thinking you would be wasting your time.
> 
> If you opened a vote for the JIT to be accepted in PHP 8, and committed 
> to making the improvements that *everyone* wants to see in the interim, 
> the vote would be more or less a formality, not really necessary at all, 
> because we all know what will happen.
> 
> I cannot stress enough that you would not be wasting your time to 
> continue developing the JIT. Saying "it's this or nothing" is not a very 
> productive or sensible thing to do at this point.
> 
> You must already know that yourself, Nikita, and Bob are really the only 
> active contributors that are qualified to talk about technical aspects 
> of the JIT, to improve it, to find or fix bugs. You must also understand 
> that given the time necessary things will change; You are employed, at 
> least in part, to work on PHP, and nobody else (afaik) except Nikita is: 
> We have to find time in our weekends and late at night to read things 
> we're not familiar with at all, I've never been good at assembly myself, 
> and my knowledge here is lacking. I look forward to improving my 
> knowledge, I find it exciting, but it will take a long time, many many 
> weekends and nights, and 7.4 is simply too early. Even Nikita and Bob 
> are not comfortable enough to make changes right now, but are still 
> useful. What we're looking at then, is a bus factor of 1, for about the 
> next year, it may be as high as 3 or 4 by the time 7.4 is actually 
> released. There's not 1000 people familiar enough with the Zend of today 
> to find, fix and improve PHP, but 3 or 4 is just unreasonably low - this 
> is the reason I say it's dangerous. My words are not meant to be toxic, 
> at all.
> 
> For the last two and a bit years, I've been focused on being a release 
> manager, and haven't spent a lot of time working on patches like I used 
> too, I'm still familiar with zend at a low level, but you've just made 
> it 100x more complicated, and are twisting our arms to accept this 
> additional complexity, all the while saying you won't make improvements 
> and don't have time for other improvements that you've identified that 
> would widen the scope of the JIT considerably (ZTS), and lay the 
> groundwork for supporting other platforms (Windows).
> 
> 7.3 was one of the worst releases for stability in recent years, and 
> regardless of whether you intend to disable the JIT by default, it's 
> going to be rolled out into production in whatever version of PHP it is 
> merged into, if what it is merged into is a production release of PHP, 
> you can't stop that with a configure switch or an INI setting, as has 
> already been pointed out by Nikita. Therefore, it's important that the 
> JIT is actually production ready and has a scope wide enough to justify 
> the additional complexity it brings to everything. I'm aware that you 
> think switching the JIT off is a solution to the tooling problems we 
> clearly have, but it is not a solution, people are going to expect their 
> tools to work with it, and saying "disable the JIT" or "disable opcache" 
> to end users is unacceptable. I realise you have more important things 
> to do right now than to concentrate on the issues that extension 
> maintainers have, but it's obvious that these issues need to be 
> addressed before we push the JIT onto the ecosystem. By withdrawing the 
> suggestion of merging into 7.4, and focusing our efforts on a really 
> great PHP 8, you give yourself and all those maintainers time to work 
> together and find solutions to these problems that are acceptable to us 
> all, time we all desperately need. yourself included. You also reduce 
> your own workload considerably by not having to concentrate on 7.4. You 
> also take away the worry of another unstable release in the 7 series, 
> which we cannot really afford to have if we don't want to damage 
> adoption rates of PHP 8.
> 
> Yesterday the suggestion of "preview" releases was made, previews of the 
> master branch, this is the best idea I have heard around deploying the 
> JIT to the world, those releases need not have a fixed schedule and in 
> no sense are production 

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

Morning Dmitry,

> I told, I'm not going to do any active JIT development at this point.
> Why to waste time, if it's not going to be accepted...

At this point, *nobody* can imagine that PHP 8 will not have a JIT, there
is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed to
making the improvements that *everyone* wants to see in the interim, the
vote would be more or less a formality, not really necessary at all,
because we all know what will happen.

I cannot stress enough that you would not be wasting your time to continue
developing the JIT. Saying "it's this or nothing" is not a very productive
or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only
active contributors that are qualified to talk about technical aspects of
the JIT, to improve it, to find or fix bugs. You must also understand that
given the time necessary things will change; You are employed, at least in
part, to work on PHP, and nobody else (afaik) except Nikita is: We have to
find time in our weekends and late at night to read things we're not
familiar with at all, I've never been good at assembly myself, and my
knowledge here is lacking. I look forward to improving my knowledge, I find
it exciting, but it will take a long time, many many weekends and nights,
and 7.4 is simply too early. Even Nikita and Bob are not comfortable enough
to make changes right now, but are still useful. What we're looking at
then, is a bus factor of 1, for about the next year, it may be as high as 3
or 4 by the time 7.4 is actually released. There's not 1000 people familiar
enough with the Zend of today to find, fix and improve PHP, but 3 or 4 is
just unreasonably low - this is the reason I say it's dangerous. My words
are not meant to be toxic, at all.

For the last two and a bit years, I've been focused on being a release
manager, and haven't spent a lot of time working on patches like I used
too, I'm still familiar with zend at a low level, but you've just made it
100x more complicated, and are twisting our arms to accept this additional
complexity, all the while saying you won't make improvements and don't have
time for other improvements that you've identified that would widen the
scope of the JIT considerably (ZTS), and lay the groundwork for supporting
other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and
regardless of whether you intend to disable the JIT by default, it's going
to be rolled out into production in whatever version of PHP it is merged
into, if what it is merged into is a production release of PHP, you can't
stop that with a configure switch or an INI setting, as has already been
pointed out by Nikita. Therefore, it's important that the JIT is actually
production ready and has a scope wide enough to justify the additional
complexity it brings to everything. I'm aware that you think switching the
JIT off is a solution to the tooling problems we clearly have, but it is
not a solution, people are going to expect their tools to work with it, and
saying "disable the JIT" or "disable opcache" to end users is unacceptable.
I realise you have more important things to do right now than to
concentrate on the issues that extension maintainers have, but it's obvious
that these issues need to be addressed before we push the JIT onto the
ecosystem. By withdrawing the suggestion of merging into 7.4, and focusing
our efforts on a really great PHP 8, you give yourself and all those
maintainers time to work together and find solutions to these problems that
are acceptable to us all, time we all desperately need. yourself included.
You also reduce your own workload considerably by not having to concentrate
on 7.4. You also take away the worry of another unstable release in the 7
series, which we cannot really afford to have if we don't want to damage
adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the
master branch, this is the best idea I have heard around deploying the JIT
to the world, those releases need not have a fixed schedule and in no sense
are production releases of PHP. I'll happily volunteer myself to do that
additional work and manage those releases while the 7.4 release managers
concentrate on a stable 7.4, I'm quite sure that past release managers will
help me there too. We can then nominate permanent managers for 8 as normal,
and I/we will hand over to them a reasonably stable, well tested JIT, that
many of us are comfortable diagnosing and pushing forward.

> If you are interested in ZTS, you may invest time in implementation of
> the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
> if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was
myself that prepared for PHP 7 the original native-tls patch that was
proposed some time 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi,

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

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

If you are interested in ZTS, you may invest time in implementation of 
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me 
if you start, because I may find time myself.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported 
problems, respond to code review comments, etc (just check git commits 
history).

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

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

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

Thanks. Dmitry.


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

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