Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87277 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24165 invoked from network); 24 Jul 2015 22:09:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jul 2015 22:09:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.17.21 mout.gmx.net Received: from [212.227.17.21] ([212.227.17.21:55651] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A8/81-10459-487B2B55 for ; Fri, 24 Jul 2015 18:09:09 -0400 Received: from [192.168.0.100] ([95.89.139.132]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfRnb-1ZXwOQ371P-00P6kF; Sat, 25 Jul 2015 00:09:05 +0200 Message-ID: <55B2B78A.4080202@gmx.de> Date: Sat, 25 Jul 2015 00:09:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anatol Belski , 'Pierre Joye' CC: 'PHP internals' References: <55B0CADD.8000807@gmx.de> <55B136BE.8010006@gmx.de> <046401d0c644$9cf76880$d6e63980$@belski.net> In-Reply-To: <046401d0c644$9cf76880$d6e63980$@belski.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:x8wmfPHJgDJDTc0JOhJUq6tNWW6vKo72Xl4H7Xw3VtrTy4CFUIs kOssApYL3/TbN68bCk5e2CaLni8WSl2FMTWq2nNhkFmd9hyXUIIOJLs3tjNRN1aKxeSx9aR eNMJhAuRTxhkTzUJ2eswiDTjQGkCmWp5+0KbEJyby7lETQh9pCab29KRM9kj6tifWJij0wZ B+RrSTVBb63TtBGDdbZAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OIuzZMx9DJg=:pEkg466Mywe5hvmvKTMQML 2cJMprGEp2Rq5/zpIwL7tDDzous4AZyb9tka63MFfGw+h+6rPQB7sm9HgFKYi6sD+257nmFiR UX7+FrvAg0engYBgiXlAKMRcMqHNrXVVcIGeuzBhglpPfsJIYutHSp9HMr3YbV+I46xE9UjAg QAP4JNRzoL23rdNmmSYK/qkN1QbsbLvUCnFzoDvsYl7Um4Rzm5wZDMYb2dV7IQ8kSqF3KekoB iIBwvGCuIax+EPxkJGwDP02t5mA9ESNprCQCQXPPQBY6b4H2m81yMRjt05jbZfm41YIyvhgOb 02VDxrnnpybUcx1xdGP5nFFDJXtXjHdhUXm4lX2kjUavGAuhvcgvLHssLdmLzwsZ8XsCLH3GV 2EEu6tVJ+3KC9lhYUvVq7LLu2z3eaalpoOZlqdyPejruUSo3CJzrkp+JzZ+aQ0rZQujX1nHZW 36U88d9fgHq2F9FWeLwzeFl+Obg3jkDEBx3xP4uit+Lk9nk7HjWdqv0Fjy0BkiF3qQFKo+HHl zOCRsaYNtKEMccqtKID3BcDZs2NVXMxyZzeNrh/V6e14JBhd5gMxcL02JUNv1VEbb7skFaa2Y PreOuX8V+tK9vNIWqC0+h27ZVsVDvxXJV3oG8Jh+V1SAN+BtBSvlgLHHBd6LYH9mfOCyrg54U AzITb7y+Pew+u0uM4GdCe/EsrsS3inftM49zvYKIr7IhToKL4ZM7ppRkMtFIsXbjnH6g= Subject: Re: [PHP-DEV] PCRE JIT stack size limit From: cmbecker69@gmx.de (Christoph Becker) Hi Anatol, Anatol Belski wrote: > This looks like an extremely fragile topic because it depends on how > much stack is available to an executable. A custom JIT stack can > behave more stable but cannot be resized. And the main issue is that > the JIT stack size, machine stack size and ext/pcre cache size are > completely unrelated terms. For example, a binary can have not enough > stack, but the custom JIT stack using mmap/VirtualAlloc could even > succeed, but then pcre_exec will be executed and overflow the machine > stack. We can never know which one is exhausted first - the one for > the JIT compilation or the other one for the execution, or vice > versa. > > Generally, moving the JIT compilation away from the machine stack and > increasing the PCRE cache size should be more stable against this . > However it's an edge case. IMHO we should not do it just to fix some > crazy usage. Users who need it might just turn off JIT. Normal usage > seems not to be affected, say loading some sane functional script, > which FE is done by any benchmark with WP, Symfony, etc. But moving > JIT compilation away from the machine stack wil lpossibly affect it. Beforehand, I'm not suggesting to change anything regarding our PCRE cache (PCRE_G(pcre_cache)); this seems to be fine as it is, and is indeed not related to this topic. Now please consider the following simple expression: preg_match('/^(foo)+$/', str_repeat('foo', $n)) This will fail (i.e. yield FALSE) independently of pcre.jit for large enough $n. However, a user can change pcre.recursion_limit what will affect the $n limit (the expression will fail for smaller or larger $n), if pcre.jit=0. If pcre.jit=1 the user can't influence this boundary in any way, currently. And maybe even worse, with pcre.jit=0 the boundary is 50,000, but with pcre.jit=1 it is only 1,366. Of course, one can argue that this is a contrived example, and that such usage is crazy, but why do we have a default pcre.recursion_limit of 100,000 then? A recursion_limit of 2,734 would be sufficient to have a boundary of $n == 1,366. All in all, as this example already suggests, classic execution of matching is done by recursive calls (using normal stack frames), while JIT execution of matching is iterative, using a special JIT stack.[1] I don't think it is justified to give users a setting to adjust for the former, but not for the latter (except to disable JIT, albeit JIT might bring quite some boost especially for such cases). As we're pretty late in the game for PHP 7.0, it might be best to postpone a new ini setting or other changes to PHP 7.1, but at the very least I would introduce a new error constant, say PHP_PCRE_JIT_STACKLIMIT_ERROR[2], so users get a more meaningful result when calling preg_last_error() than PHP_PCRE_INTERNAL_ERROR. And it seems to be appropriate to add a note to UPGRADING that pcre.jit=1 may cause some preg_*() to fail which would work with pcre.jit=0. [1] [2] -- Christoph M. Becker