On 04.08.2015 at 16:33, Anatol Belski wrote:

>> -----Original Message-----
>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
>> Sent: Tuesday, August 4, 2015 1:16 PM
>> 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
>>
>> 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.
>>
> It needs to replace the old entry, the regex string is used as key. At least 
> per current mechanism. When user changes the JIT config, I'd see it like as 
> an obvious hint. Like pcre.jit=0 - no more JIT study from now on. 

Probably you're right that replacement is best.  However, the key is the
full regex string (including modifiers), AFAIK, and Adam already came up
with the idea that choosing between JIT and non-JIT might be done via a
new modifier[1].  Something to consider, if it turns out that there is
some real optimization potential for userland to choose between both
variants on a case-by-case basis.

> Probably it would be needed to save the study flags with the cache entry, 
> looks like the pcre_cache_entry struct should have a gap for that. 

If I'm not mistaken, an additional flag wouldn't be necessary, because
the pcre_extra struct has the executable_jit field, which could be queried.

[1] <http://news.php.net/php.internals/87261>

-- 
Christoph M. Becker

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

Reply via email to