Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Message-ID: <555A81FA.5080507@gmail.com>
Date: Tue, 19 May 2015 01:21:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <55567DD2.1090608@gmx.de> <CA+kxMuRBpK80OdNZN_wR+OmBX3=nLZqcbMg8LnGX9hrqVi5Reg@mail.gmail.com> <555A70C1.9000409@gmx.de>
In-Reply-To: <555A70C1.9000409@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] trigger GC before memory limit is exhausted
From: rowan.collins@gmail.com (Rowan Collins)

On 19/05/2015 00:07, Christoph Becker wrote:
>> 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.

Apart from chewing CPU cycles, would that actually be a problem? The 
soft-limit callback would presumably be responsible for doing one of two 
things: gracefully terminating the request (the "pretty error page" use 
case) or reducing the used amount of memory (the "trigger GC" use case). 
If the memory usage was still over the soft limit when the callback 
ends, the engine could terminate as though the hard limit was reached. 
Rather than adding a soft limit, you could say that we are adding an 
additional reserve of memory only accessible to the memory-out callback.

If the callback freed at least some memory, the engine could execute at 
least one instruction before the soft limit was reached a second time, 
triggering the callback again. In the worst case, a loop could 
repeatedly push usage over the limit, triggering the callback repeatedly 
like a tick function; however, one of the following would then have to 
happen:

- the oscillation could continue for a while, but the loop or the whole 
program eventually finish normally, just a bit slower than normal
- if the net amount of memory freed by the callback was slightly higher 
than the net amount allocated after it returned, the memory usage would 
slowly decline, breaking out of the oscillation once it dropped below 
the soft limit
- if the amount of memory freed was lower than the amount allocated, the 
memory usage would slowly grow, eventually reaching the hard limit
- if the amount of memory freed and allocated was consistently 
identical, the oscillation could continue and cause the program to hit 
the execution timeout

Dynamically adjusting the limit would be no help, because if you're that 
hard up against the limit, your only hope is to gracefully end the 
process anyway.

-- 
Rowan Collins
[IMSoP]