On 15.03.2016, at 21:18, Anatol Belski <anatol....@belski.net> wrote: > > Hi, > >> -----Original Message----- >> From: David Zuelke [mailto:d...@heroku.com] >> Sent: Sunday, March 13, 2016 6:09 AM >> To: Anatol Belski <anatol....@belski.net> >> Cc: Christoph Becker <cmbecke...@gmx.de>; Pierre Joye >> <pierre....@gmail.com>; PHP internals <internals@lists.php.net> >> Subject: Re: [PHP-DEV] PCRE JIT stack size limit >> >> 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. > Could you please give a worky reproduce scenario? Itself the description > sounds like that some part in composer is not yet PHP7 ported or it's a > special case causing JIT impacts, but it were good to have a reproducer to > evaluate and make a conclusion. Till today, there was no bug reports about > PCRE JIT issues in common PHP frameworks. Except this special case > https://bugs.exim.org/show_bug.cgi?id=1189 which is fixed in PCRE 8.39 that > should be bundled as soon as possible (an eye is being kept on that).
Sure. So composer creates patterns to parse a file dynamically; I have not figured out why it only happens for some composer.json files (or maybe it happens for all of them and I just have not noticed), but this example here I extracted from a reproducibly failing "composer require" run; it runs into the JIT stack size limit on PHP 7 while it works fine on 5.x: https://gist.github.com/dzuelke/cc64a630c14416eda3e9 >> 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. > A pattern modifier could be thinkable and would be doable (sure for master, > or even for later 7.0 versions), but would cause some increased complexity > in logic for pattern cache. From the above - let's have a reproducer and > evaluate the status. Then we'll have a point for further consideration. > > Thanks > > Anatol > >> >>> 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 > >
