Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
Message-ID: <555A70C1.9000409@gmx.de>
Date: Tue, 19 May 2015 01:07:45 +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: Dan Ackroyd <danack@basereality.com>
CC: PHP Internals <internals@lists.php.net>
References: <55567DD2.1090608@gmx.de> <CA+kxMuRBpK80OdNZN_wR+OmBX3=nLZqcbMg8LnGX9hrqVi5Reg@mail.gmail.com>
In-Reply-To: <CA+kxMuRBpK80OdNZN_wR+OmBX3=nLZqcbMg8LnGX9hrqVi5Reg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] trigger GC before memory limit is exhausted
From: cmbecker69@gmx.de (Christoph Becker)

Dan Ackroyd wrote:

> On 15 May 2015 at 23:14, Christoph Becker <cmbecker69@gmx.de> wrote:
>
>> 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.

Ah, I see!  Thanks, Dan.  Having given that some thought, I can
understand that the issue has not been addressed yet.

> 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.

What happens if the soft limit is exhausted, but the GC can free only a
little memory?  That might trigger the GC shortly afterwards again and
again.  A user would have to carefully adjust the soft limit
dynamically, to work around this problem.  Then again, it might be
better than the current situation.

> 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.

I fully agree.

> 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].

That doesn't seem to work on Windows at all (at least for current
master). :(

> [1] <https://bugs.php.net/bug.php?id=41245>
> [2] <https://bugs.php.net/bug.php?id=68343>

-- 
Christoph M. Becker