Re: PCRE JIT stack size limit
| From: | Christoph Becker | Date: | Tue, 04 Aug 2015 11:15:46 +0000 |
| Subject: | Re: PCRE JIT stack size limit | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-87597@lists.php.net to get a copy of this message | ||
Hi Anatol,
On 04.08.2015 at 11:24, Anatol Belski wrote:
> Hi Christoph,
>
>> -----Original Message-----
>> From: Christoph Becker [mailto:cmbecker69@gmx.de]
>> Sent: Tuesday, August 4, 2015 2:35 AM
>> To: Anatol Belski <anatol.php@belski.net>; 'Christoph Becker'
>> <cmbecker69@gmx.de>; 'Pierre Joye' <pierre.php@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:cmbecker69@gmx.de]
>>>> Sent: Monday, July 27, 2015 12:06 AM
>>>> To: Anatol Belski <anatol.php@belski.net>; 'Pierre Joye'
>>>> <pierre.php@gmail.com>
>>>> Cc: 'PHP internals' <internals@lists.php.net>
>>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>>>>
>> 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.
Ah, I see. Then we ought to prominently document that chaning the
setting during script execution might not have the desired effect due to
internal caching.
>> 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?
I didn't mean to store all patterns in both variants, but rather as
requested. Say, the PHP script starts with pcre.jit=0, so all patterns
will be stored studied without JIT. Then the script changes to
pcre.jit=1. Following cache lookups check whether an already cached
pattern was studied with JIT. If not, a new cache entry is made with
the pattern studied with JIT (that new entry may replace the old one or
not; not sure what's best). Changing back to pcre.jit=0 will again keep
the old patterns, but ensures that only those which have been studied
without JIT are retrieved from the cache.
--
Christoph M. Becker