RE: [PHP-DEV] PCRE JIT stack size limit

Hi Christoph, > -----Original Message----- > From: Christoph Becker [mailto:cmbecker69@gmx.de] > Sent: Tuesday, August 4, 2015 7:40 PM > 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 04.08.2015 at 16:33, Anatol Belski wrote: > > >> -----Original Message----- > >> From: Christoph Becker [mailto:cmbecker69@gmx.de] > >> Sent: Tuesday, August 4, 2015 1:16 PM > >> 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 > >> > >> 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. > Yeah, that were a nice approach. Should be checked probably, whether there's a corresponding perl pattern modifier (probably there is none, but shouldn't be that bad). And also to evaluate what behavior were produced when say jit is disabled but a modifier is passed. > > 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. > Ok, that would be even better, given it's reliable. Regards Anatol