Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87630
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Christoph Becker'" <cmbecker69@gmx.de>,
	"'Pierre Joye'" <pierre.php@gmail.com>
Cc: "'PHP internals'" <internals@lists.php.net>
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>
In-Reply-To: <55C0F908.2050708@gmx.de>
Date: Tue, 4 Aug 2015 23:20:46 +0200
Message-ID: <068e01d0cefb$6ffba3e0$4ff2eba0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHD9RJvenw/Ss5kSkuHSfZFOrs2uQBWRtPIAqC4oYQC1yvg/gL/4swBAjr9PxcCDsvXWAGHs1w9AZmBwtoBoC/PpAI/kFTiAkX1QGcB3tOhmwMEMgs1AT7oJdYAllO0wAKAL1FjnRlRVGA=
Content-Language: en-us
Subject: RE: [PHP-DEV] PCRE JIT stack size limit
From: anatol.php@belski.net ("Anatol Belski")

Hi Christoph,

> -----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
> >>
> >> 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.

> > 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.

Regards

Anatol