Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87611 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62868 invoked from network); 4 Aug 2015 14:33:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2015 14:33:50 -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:42805] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6D/52-49831-C4DC0C55 for ; Tue, 04 Aug 2015 10:33:48 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 80E6823D6003; Tue, 4 Aug 2015 16:33:45 +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 9B6DB23D6003; Tue, 4 Aug 2015 16:33:43 +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> <05ec01d0ce97$4ee7c4e0$ecb74ea0$@belski.net> <55C09EE2.7010400@gmx.de> In-Reply-To: <55C09EE2.7010400@gmx.de> Date: Tue, 4 Aug 2015 16:33:41 +0200 Message-ID: <063f01d0cec2$91b9baf0$b52d30d0$@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/kFTiAkX1QGcB3tOhmwMEMgs1AT7oJdadMZVpoA== Content-Language: en-us Subject: RE: [PHP-DEV] PCRE JIT stack size limit From: anatol.php@belski.net ("Anatol Belski") > -----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. >=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. 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. But actually sounds like an approach. Regards Anatol