Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91683 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23094 invoked from network); 15 Mar 2016 20:18:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Mar 2016 20:18:22 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:53463] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3A/E3-00207-B0E68E65 for ; Tue, 15 Mar 2016 15:18:20 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 3C41F782AA8; Tue, 15 Mar 2016 21:18:16 +0100 (CET) Received: from w530phpdev (pD9FD2446.dip0.t-ipconnect.de [217.253.36.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 18776782A72; Tue, 15 Mar 2016 21:18:12 +0100 (CET) To: "'David Zuelke'" Cc: "'Christoph Becker'" , "'Pierre Joye'" , "'PHP internals'" References: <55B0CADD.8000807@gmx.de> <55B136BE.8010006@gmx.de> <046401d0c644$9cf76880$d6e63980$@belski.net> <55B2B78A.4080202@gmx.de> <048001d0c665$ed19ec40$c74dc4c0$@belski.net> <55B2D779.9090409@gmx.de> <04d301d0c6e5$6b28f0c0$417ad240$@belski.net> <55B3B2E6.7080905@gmx.de> <056e01d0c7d9$b1edd990$15c98cb0$@belski.net> <55B559C7.9060304@gmx.de> <064301d0c85f$5260ac60$f7220520$@belski.net> <55C008B1.2050008@gmx.de> <05ec01d0ce97$4ee7c4e0$ecb74ea0$@belski.net> <55C09EE2.7010400@gmx.de> <063f01d0cec2$91b9baf0$b52d30d0$@belski.net> <55C0F908.2050708@gmx.de> <068e01d0cefb$6ffba3e0$4ff2eba0$@belski.net> In-Reply-To: Date: Tue, 15 Mar 2016 21:18:06 +0100 Message-ID: <016e01d17ef7$cd8a2660$689e7320$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHD9RJvenw/Ss5kSkuHSfZFOrs2uQBWRtPIAqC4oYQC1yvg/gL/4swBAjr9PxcCDsvXWAGHs1w9AZmBwtoBoC/PpAI/kFTiAkX1QGcB3tOhmwMEMgs1AT7oJdYAllO0wAKAL1FjAiFBQeICQV6Jkp5WNqUQ Content-Language: en-us Subject: RE: [PHP-DEV] PCRE JIT stack size limit From: anatol.php@belski.net ("Anatol Belski") Hi, > -----Original Message----- > From: David Zuelke [mailto:dz@heroku.com] > Sent: Sunday, March 13, 2016 6:09 AM > To: Anatol Belski > Cc: Christoph Becker ; Pierre Joye > ; PHP internals > 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). > 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 wrote: > > > > Hi Christoph, > > > >> -----Original Message----- > >> From: Christoph Becker [mailto:cmbecker69@gmx.de] > >> Sent: Tuesday, August 4, 2015 7:40 PM > >> To: Anatol Belski ; 'Christoph Becker' > >> ; 'Pierre Joye' > >> Cc: 'PHP internals' > >> 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 ; 'Christoph Becker' > >>>> ; 'Pierre Joye' > >>>> Cc: 'PHP internals' > >>>> 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