Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86303
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <555B4889.7030808@gmail.com>
Date: Tue, 19 May 2015 15:28:25 +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" <internals@lists.php.net>
References: <55567DD2.1090608@gmx.de>	<CA+kxMuRBpK80OdNZN_wR+OmBX3=nLZqcbMg8LnGX9hrqVi5Reg@mail.gmail.com>	<555A70C1.9000409@gmx.de>	<555A81FA.5080507@gmail.com> <CA+kxMuRJiz10B8YmLbDO=wnGcY23zX-07egYHu+SktkfYMxzRw@mail.gmail.com>
In-Reply-To: <CA+kxMuRJiz10B8YmLbDO=wnGcY23zX-07egYHu+SktkfYMxzRw@mail.gmail.com>
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)

Dan Ackroyd wrote on 19/05/2015 14:08:
> * When gc_collect_cycles is called (and potentially other functions),
> at the end of that function check whether the amount of memory being
> used is less than reset level for each trigger. If so reduce the
> current memory limit to the lowest trigger level.

The only flaw I see in this approach is that the majority of memory 
deallocation is done transparently be the ref-counting mechanism, not 
any particular function, and the user should be able to trigger this 
manually.

For instance, you might have an EntityRepository which caches all the 
entities it's loaded thus far in the script to save DB round trips, and 
calling clearCache() on this repository might free a significant amount 
of memory.

It would probably make sense for the memory level to be checked against 
reset levels immediately after the low-memory callback returns, so that 
users can deliberately take advantage of such deallocations. However, 
that still leaves the case of that method being called during normal 
flow, and requiring a call to gc_collect_cycles just for the side-effect 
of resetting memory limits seems a bit odd.

I don't know enough about the memory manager to know, but presumably at 
the moment memory_limit is checked on every allocation? Could a similar 
check be made on deallocation?

Having multiple levels configured doesn't actually have any extra 
performance cost, except in the case where they are all passed at once - 
you just store the "current" level, and test whether you have reached 
the next level up or down. If a single deallocation drops you from 20MB 
to 2MB, you first register that the 16MB reset limit has been reached, 
and *only then* perform an extra check if the 8MB reset limit has also 
been reached.

Regards,
-- 
Rowan Collins
[IMSoP]