Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86240 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48326 invoked from network); 16 May 2015 00:42:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 May 2015 00:42:22 -0000 Authentication-Results: pb1.pair.com header.from=danack@basereality.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=danack@basereality.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.169 cause and error) X-PHP-List-Original-Sender: danack@basereality.com X-Host-Fingerprint: 209.85.160.169 mail-yk0-f169.google.com Received: from [209.85.160.169] ([209.85.160.169:33020] helo=mail-yk0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E7/50-45600-C6296555 for ; Fri, 15 May 2015 20:42:21 -0400 Received: by ykeo186 with SMTP id o186so38974193yke.0 for ; Fri, 15 May 2015 17:42:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BWIr85R1GgtyFbTcbP6sR2MYX8kpTOkcivTTMdgEbzE=; b=EJrLiCWPTyJzp6VTdaQktiFM+R8WWgEgBLI6cTR0QUMucJiJMkX+bK1hUWjcwgQSB1 1NY7vbDFm3B9Q6I+N3JA2grhlA9IrA/Penm8qqb0cHIEaasjrQiZ5ddqGg0t6vnBLF9C enfniAC3dFNrhTsSQif2Uf9Xe2UZWzqfqfPeNP7bnq+P0/dhTQwzb6dONmvHUPi1f4Fd SojPa6PAnA2WH/AwqBWl1Zf/gl1ie2Tke7VitLa22qNcOQV1fIzTL/Rn31yIICMIXls/ dgdsVuHc8aHI99/tPMBYYPP1jG3QYEK/8krI8XiTIxlSRh7lc5oppH25/vLr9gwdXfDF iTdw== X-Gm-Message-State: ALoCoQmNIdY+N4XFNqTn1lujfRhDmSxPAkmvrdxODEgtdTwudGvewxrNu0VsWxmZSagZVTUHenLp MIME-Version: 1.0 X-Received: by 10.236.26.111 with SMTP id b75mr783791yha.110.1431736938075; Fri, 15 May 2015 17:42:18 -0700 (PDT) Received: by 10.129.108.75 with HTTP; Fri, 15 May 2015 17:42:18 -0700 (PDT) X-Originating-IP: [89.242.229.174] In-Reply-To: <55567DD2.1090608@gmx.de> References: <55567DD2.1090608@gmx.de> Date: Sat, 16 May 2015 00:42:18 +0000 Message-ID: To: Christoph Becker Cc: PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] trigger GC before memory limit is exhausted From: danack@basereality.com (Dan Ackroyd) Hi Christopher, On 15 May 2015 at 23:14, Christoph Becker wrote: > Hello internals, > > today I have been pointed to bug #60982[1], which appears to be an > unpleasant limitation. > It sure is! > I wonder why the GC is not triggered when the memory limit is exhausted, To hopefully point you in the right direction, I believe the problem I ran into, and the issue that stops it being a trivial thing to fix is this; it can be necessary for memory allocations to take place inside gc_collect_cycles. For example when an object has a userland __destruct method, and it is destroyed when the GC runs, then calling that method should require allocations.....but we've already run out of memory, so that can't happen. As Rasmus suggested[1], in an issue linked through #60982, a simple way to solve this would be to have both a soft and hard limit for memory, and to allow the soft-limit to be a user callback, which could call gc_collect_cycles, or not as the user desired. However, it might be time to give the garbage collector a bit of love and care, as it's not necessarily the case that the GC requirements for PHP running as CGI process are the same as it running as a long-running CLI process. If nothing else, it would be nice to get the GC_BENCH benchmark stuff working for the CLI again; it currently only works in certain circumstances[2]. cheers Dan [1] [2]