Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86239 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43459 invoked from network); 15 May 2015 23:14:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 May 2015 23:14:22 -0000 Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.15.15 mout.gmx.net Received: from [212.227.15.15] ([212.227.15.15:59778] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 86/00-42372-CCD76555 for ; Fri, 15 May 2015 19:14:21 -0400 Received: from [192.168.0.101] ([88.134.68.210]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LzKmP-1ZFgjJ46jJ-014PW2 for ; Sat, 16 May 2015 01:14:17 +0200 Message-ID: <55567DD2.1090608@gmx.de> Date: Sat, 16 May 2015 01:14:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: PHP Internals Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:csBDauEk6sagyYqD9N83vlfDeaKmAMGQ72NbXJDR6HVMo/MTcGS UtqjJxvjjo0EfPc1QfOnxKe2wBId+HCrx9qAUQxiuvvMxBSUZculYBJauDMOfEx0FTlID1a G01ADH8fX1w4K+8kIwGRxD91GJIm2ZDqDbLiylMOZZN/YEqbtJF+ay1foplQxCkLPL0aMhN 9Fr/vSSl/yYqkFcMhMHNw== X-UI-Out-Filterresults: notjunk:1; Subject: trigger GC before memory limit is exhausted From: cmbecker69@gmx.de (Christoph Becker) Hello internals, today I have been pointed to bug #60982[1], which appears to be an unpleasant limitation. I wonder why the GC is not triggered when the memory limit is exhausted, what would avoid the script to end prematurely if there are uncollected cycles. I've tried out a (maybe too simplistic) solution[2], and with that modification the test script of bug #69639[3] would run, as well as Dan Ackroyd's memTest.php[4] presented in the other bug report. With my limited knowledge of C, systems programming, and the Zend Engine in particular, I can't see any drawbacks with this modification, so I would be happy if more experienced programmers could point out crucial issues. Otherwise it might be worthwhile to investigate further improvements (I have not tackled zend_mm_realloc_heap() or even "Out of memory" conditions). [1] [2] [3] [4] -- Christoph M. Becker