Dan Ackroyd wrote: > On 15 May 2015 at 23:14, Christoph Becker <cmbecke...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
