Hi Christopher, On 15 May 2015 at 23:14, Christoph Becker <cmbecke...@gmx.de> 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] <https://bugs.php.net/bug.php?id=41245> [2] <https://bugs.php.net/bug.php?id=68343> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
