Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87317 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77804 invoked from network); 27 Jul 2015 11:28:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jul 2015 11:28:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; 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:39930] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/E1-61854-0D516B55 for ; Mon, 27 Jul 2015 07:28:17 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 061DA23D629F; Mon, 27 Jul 2015 13:28:13 +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 (pD9FD268F.dip0.t-ipconnect.de [217.253.38.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 3578423D6003; Mon, 27 Jul 2015 13:28:11 +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> In-Reply-To: <55B559C7.9060304@gmx.de> Date: Mon, 27 Jul 2015 13:28:09 +0200 Message-ID: <064301d0c85f$5260ac60$f7220520$@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/kFTinWf3qUA= 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: Monday, July 27, 2015 12:06 AM > To: Anatol Belski ; 'Pierre Joye' > > Cc: 'PHP internals' > Subject: Re: [PHP-DEV] PCRE JIT stack size limit >=20 > 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. >=20 > FWIW, some hours ago I've implemented the clean whole cache solution: > src/commit/c41d78046da48db2fa8f5bd82fd6ac58099288f8>. >=20 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. > >>> Running for the INI option and some custom JIT stack functionality > >>> needs > >> more brainstorming and test. Please ping when you have an initial > >> implementation, I'd be glad to help testing, etc. anyway. > >> > >> All in all it seems that we probably should have an RFC for that. > >> I'll consider to write one, but there's no need to hurry =E2=80=93 = too late > >> for 7.0 anyway. :) > >> > > Yep, the whole needs a good consideration about how to do it best > > without a big impact on the user side. Also probably it could be = worth > > it to check how PCRE2 behaves in this cases, maybe it were = worthwhile to > upgrade to PCRE2 for 7.1. >=20 > Indeed, offering support for PCRE2 should be considered for 7.1. And = also > support of the JIT fast path API: > . >=20 Yes, maybe we'll have to support both for a while because PCRE2 is quite = new so it'll need quite some time distros catch up. Thanks Anatol