Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91647
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heroku.com designates 74.125.82.42 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <068e01d0cefb$6ffba3e0$4ff2eba0$@belski.net>
Date: Sun, 13 Mar 2016 06:09:14 +0100
Cc: Christoph Becker <cmbecker69@gmx.de>,
 Pierre Joye <pierre.php@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A428AF35-A176-404D-888C-7541100155B2@heroku.com>
References: <55B0CADD.8000807@gmx.de> <CAEZPtU7aPzPQ=DL5fn9fOEuU_hySm5WXUkbjFw+Sq0T5xNfb3A@mail.gmail.com> <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>
To: Anatol Belski <anatol.php@belski.net>
Subject: Re: [PHP-DEV] PCRE JIT stack size limit
From: dz@heroku.com (David Zuelke)

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.php@belski.net> 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 <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
>>=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 <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
>>>>=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.
>>>>=20
>>> 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.
>>=20
> 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.
>>=20
> 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