Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87596 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25478 invoked from network); 4 Aug 2015 09:24:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2015 09:24:13 -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:34875] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0B/00-24673-9B480C55 for ; Tue, 04 Aug 2015 05:24:11 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 77EAA23D629F; Tue, 4 Aug 2015 11:24:06 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on h1123647.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable version=3.3.2 Received: from w530phpdev (p579F32E2.dip0.t-ipconnect.de [87.159.50.226]) (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 16B1B23D6003; Tue, 4 Aug 2015 11:24:03 +0200 (CEST) To: "'Christoph Becker'" , "'Pierre Joye'" Cc: "'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> In-Reply-To: <55C008B1.2050008@gmx.de> Date: Tue, 4 Aug 2015 11:24:00 +0200 Message-ID: <05ec01d0ce97$4ee7c4e0$ecb74ea0$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHD9RJvenw/Ss5kSkuHSfZFOrs2uQBWRtPIAqC4oYQC1yvg/gL/4swBAjr9PxcCDsvXWAGHs1w9AZmBwtoBoC/PpAI/kFTiAkX1QGcB3tOhm51TUJPA 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 2:35 AM > To: Anatol Belski ; 'Christoph Becker' > ; 'Pierre Joye' > Cc: 'PHP internals' > Subject: Re: [PHP-DEV] PCRE JIT stack size limit >=20 > On 27.07.2015 at 13:28, Anatol Belski wrote: >=20 > >> -----Original Message----- > >> From: Christoph Becker [mailto:cmbecker69@gmx.de] > >> Sent: Monday, July 27, 2015 12:06 AM > >> To: Anatol Belski ; 'Pierre Joye' > >> > >> Cc: 'PHP internals' > >> Subject: Re: [PHP-DEV] PCRE JIT stack size limit > >> > >> Definitely interesting ideas. However, currently I'm leaning = towards > >> a full- fledged solution in PHP 7.1 (whatever that may be), and to > >> only add the error constant for PHP 7.0. Users can set = pcre.jit=3D0 in > >> php.ini and not change the setting during runtime, if necessary. > >> > >> FWIW, some hours ago I've implemented the clean whole cache = solution: > >> >> src/commit/c41d78046da48db2fa8f5bd82fd6ac58099288f8>. > > > > I wrote this script to test it > https://gist.github.com/weltling/cd7f8127378989cca87c , but as = expected - > cache reset make a significant impact when the cache is full. Though, = maybe as > it's an exceptional situation, it were the simplest solution. Because = it does not > affect the normal usage, maybe it's ok for 7.0. Maybe we should give = this > flexibility, still in doubt. But the constant IMHO should be done = anyway. >=20 > IMHO we shouldn't introduce the cache clearing. As your test script = shows, the > performance might suffer considerably when switching pcre.jit in a = running > script. Furthermore cached regexps currently in use (e.g. > via preg_replace_callback) can't be cleared, what might lead to = confusion (in > very rare cases, though). >=20 > As it is now users can set pcre.jit=3D0 and so will retain full = compatibility with PHP > 5. If they're running with pcre.jit=3D1, they're able to get a = meaningful error > (PREG_JIT_STACKLIMIT_ERROR), if the default stack is not large enough = (what > indeed might rarely be the case). >=20 Same opinion here. > If we leave it as this, I suggest to make pcre.jit PHP_INI_PERDIR = instead of > PHP_INI_ALL for PHP 7.0. That still gives users the option to disable = it (ideally > even on shared hosting), but avoids issues when dynamically switching = the > setting with regard to our regexp caching. If we find a better = solution for PHP > 7.1, we still can extend it to PHP_INI_ALL without a BC break. > That would disable possibility to change it in the registry which is = PHP_INI_USER. That's something about shared hosting, too. =20 > For PHP 7.1 it might be worthwhile to consider to store jitted resp. > non-jitted regexps in the cache, and to fetch what fits to the current = setting of > pcre.jit (and otherwise to compile again, adding the new entry to the = cache, or > maybe replacing it). >=20 Not sure to understand what you mean. Storing every pattern in both = variants studied with and without JIT? Regards Anatol