Hi Christoph, > -----Original Message----- > From: Christoph Becker [mailto:cmbecke...@gmx.de] > Sent: Tuesday, August 4, 2015 2:35 AM > To: Anatol Belski <anatol....@belski.net>; 'Christoph Becker' > <cmbecke...@gmx.de>; 'Pierre Joye' <pierre....@gmail.com> > Cc: 'PHP internals' <internals@lists.php.net> > Subject: Re: [PHP-DEV] PCRE JIT stack size limit > > On 27.07.2015 at 13:28, Anatol Belski wrote: > > >> -----Original Message----- > >> From: Christoph Becker [mailto:cmbecke...@gmx.de] > >> Sent: Monday, July 27, 2015 12:06 AM > >> To: Anatol Belski <anatol....@belski.net>; 'Pierre Joye' > >> <pierre....@gmail.com> > >> Cc: 'PHP internals' <internals@lists.php.net> > >> Subject: Re: [PHP-DEV] PCRE JIT stack size limit > >> > >> Definitely interesting ideas. However, currently I'm leaning towards > >> a full- fledged solution in PHP 7.1 (whatever that may be), and to > >> only add the error constant for PHP 7.0. Users can set pcre.jit=0 in > >> php.ini and not change the setting during runtime, if necessary. > >> > >> FWIW, some hours ago I've implemented the clean whole cache solution: > >> <https://github.com/cmb69/php- > >> src/commit/c41d78046da48db2fa8f5bd82fd6ac58099288f8>. > > > > I wrote this script to test it > https://gist.github.com/weltling/cd7f8127378989cca87c , but as expected - > cache reset make a significant impact when the cache is full. Though, maybe as > it's an exceptional situation, it were the simplest solution. Because it does > not > affect the normal usage, maybe it's ok for 7.0. Maybe we should give this > flexibility, still in doubt. But the constant IMHO should be done anyway. > > IMHO we shouldn't introduce the cache clearing. As your test script shows, > the > performance might suffer considerably when switching pcre.jit in a running > script. Furthermore cached regexps currently in use (e.g. > via preg_replace_callback) can't be cleared, what might lead to confusion (in > very rare cases, though). > > As it is now users can set pcre.jit=0 and so will retain full compatibility > with PHP > 5. If they're running with pcre.jit=1, they're able to get a meaningful error > (PREG_JIT_STACKLIMIT_ERROR), if the default stack is not large enough (what > indeed might rarely be the case). > Same opinion here.
> If we leave it as this, I suggest to make pcre.jit PHP_INI_PERDIR instead of > PHP_INI_ALL for PHP 7.0. That still gives users the option to disable it > (ideally > even on shared hosting), but avoids issues when dynamically switching the > setting with regard to our regexp caching. If we find a better solution for > PHP > 7.1, we still can extend it to PHP_INI_ALL without a BC break. > That would disable possibility to change it in the registry which is PHP_INI_USER. That's something about shared hosting, too. > For PHP 7.1 it might be worthwhile to consider to store jitted resp. > non-jitted regexps in the cache, and to fetch what fits to the current > setting of > pcre.jit (and otherwise to compile again, adding the new entry to the cache, > or > maybe replacing it). > Not sure to understand what you mean. Storing every pattern in both variants studied with and without JIT? Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
