Just wanted to resurrect this thread... I just got a JIT stack size limit error (which Composer reports as "unknown error" because it has no logic for the new constant) while running "composer require somepackage" with PHP 7 and JIT enabled.
IMO, a pattern modifier would be good so that applications can disable JIT on demand. I'd also like to re-start a discussion on changing the default for pcre.jit to 0. > On 04.08.2015, at 23:20, Anatol Belski <anatol....@belski.net> wrote: > > Hi Christoph, > >> -----Original Message----- >> From: Christoph Becker [mailto:cmbecke...@gmx.de] >> Sent: Tuesday, August 4, 2015 7:40 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 >> >> 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. >> > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
