Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91685 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 32514 invoked from network); 15 Mar 2016 22:57:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Mar 2016 22:57:42 -0000 Authentication-Results: pb1.pair.com header.from=dz@heroku.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dz@heroku.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain heroku.com designates 74.125.82.49 as permitted sender) X-PHP-List-Original-Sender: dz@heroku.com X-Host-Fingerprint: 74.125.82.49 mail-wm0-f49.google.com Received: from [74.125.82.49] ([74.125.82.49:35475] helo=mail-wm0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/F4-00207-46398E65 for ; Tue, 15 Mar 2016 17:57:41 -0500 Received: by mail-wm0-f49.google.com with SMTP id l68so168532392wml.0 for ; Tue, 15 Mar 2016 15:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heroku-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uOrMBRvB2OR36aZoHYYOUuHOjXanmEcKYcqIMvUNghM=; b=Dh7u5EE6GdpAWqoILe4hN4F+ui4nEcNGY75G8hvxA2iV4BHyE0/mYTPqhKKYERAMGl erUFKrqEAt3WYBMTnDvz8D0h4oXfUr0wddSm3CjnDKBMGJZJOxKMl7pbA1UZZ+5WQHgA ztOOLLp3TVWdXoO58xOStXYCRY6MRN7Ayi4ku1TN55ms0gJKVqYPbsb7D/8Y1i909r40 D8h09Av4Z1ukOL6P2P8NOIB/JLiYGYx22Dlguz05jzvPPuDjqkuKx7reRP4y6kFielUh VmmqLWca4RkvHMnP7LRqn6D0mgkQif0eVqZF7DZ00j5l+zQMwh3I/wt4vXDKBAIWR3j8 qWEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uOrMBRvB2OR36aZoHYYOUuHOjXanmEcKYcqIMvUNghM=; b=a2aETEEFRdpxz9rveZN+66p6ck8r3Z/+mRQ1x4EbN4CiXIN1yucJypWHzqA0cxcg1o aTy/qh4EQbsQHhrGJUSYvAQi18H95Hnkvhtd5QabRpUXAm435x8/dLagJGBI+YcNuiYr G3hj2kHYJcE2y7ka55uNRuBVUhddtrh35x5Ar3nKJJiSYCGbf2xBp1/gVUapwX0lHM3W IWHP8GvMqrrTQ8zky/5Dtg52ahYd7XzZfXDxE6x8TNGCUOtp43QQRCI47Gab/WVplkk0 Gb8mC8K3CSH3jv9QD5/8yAe7AwCdFdn6uv4QRiXax0dbfvYf98fmvQrMtDVw1NaKa1O0 YQWQ== X-Gm-Message-State: AD7BkJLPuVAaoobTtE0eQhT9m+paW3s+oLkhpiEj+9pcKkqK2Y0VJxMCNcelmPAdtfBltgLZ X-Received: by 10.28.187.212 with SMTP id l203mr950058wmf.73.1458082657773; Tue, 15 Mar 2016 15:57:37 -0700 (PDT) Received: from [10.113.5.91] (ip-109-47-0-123.web.vodafone.de. [109.47.0.123]) by smtp.gmail.com with ESMTPSA id i5sm322814wjx.15.2016.03.15.15.57.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 15:57:36 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AF95A30E-D8BE-4B71-9341-13DE9CD62DBE Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (13D15) In-Reply-To: <016e01d17ef7$cd8a2660$689e7320$@belski.net> Date: Tue, 15 Mar 2016 23:57:34 +0100 Cc: Christoph Becker , Pierre Joye , PHP internals Content-Transfer-Encoding: 7bit Message-ID: <25D67B35-88FF-4A5C-9421-BAF482B32A96@heroku.com> 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> <016e01d17ef7$cd8a2660$689e7320$@belski.net> To: Anatol Belski Subject: Re: [PHP-DEV] PCRE JIT stack size limit From: dz@heroku.com (David Zuelke) --Apple-Mail-AF95A30E-D8BE-4B71-9341-13DE9CD62DBE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 15.03.2016, at 21:18, Anatol Belski wrote: >=20 > Hi, >=20 >> -----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 >>=20 >> 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=3D1189 which is fixed in PCRE 8.39 t= hat > 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 f= igured out why it only happens for some composer.json files (or maybe it hap= pens for all of them and I just have not noticed), but this example here I e= xtracted from a reproducibly failing "composer require" run; it runs into th= e 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 JI= T > on >> demand. >>=20 >> 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. =46rom the above - let's have a reproducer and= > evaluate the status. Then we'll have a point for further consideration. >=20 > Thanks >=20 > Anatol >=20 >>=20 >>> On 04.08.2015, at 23:20, Anatol Belski wrote: >>>=20 >>> Hi Christoph, >>>=20 >>>> -----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 >>>>=20 >>>> On 04.08.2015 at 16:33, Anatol Belski wrote: >>>>=20 >>>>>> -----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 >>>>>>=20 >>>>>> I didn't mean to store all patterns in both variants, but rather as >>>>>> requested. Say, the PHP script starts with pcre.jit=3D0, so all >>>>>> patterns will be stored studied without JIT. Then the script >>>>>> changes to pcre.jit=3D1. 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=3D0 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=3D0 - no more JIT study from now on. >>>>=20 >>>> 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. >>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> Regards >>>=20 >>> Anatol >>>=20 >>>=20 >>> -- >>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >>> visit: http://www.php.net/unsub.php >=20 >=20 --Apple-Mail-AF95A30E-D8BE-4B71-9341-13DE9CD62DBE--