On 19/05/2015 00:07, Christoph Becker wrote:
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.
The usual way to stop this sort of flapping is to set the point at
which the alarm gets reset to be
On 19 May 2015 at 14:28, Rowan Collins rowan.coll...@gmail.com wrote:
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
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.
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
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
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
Hello internals,
today I have been pointed to bug #60982[1], which appears to be an
unpleasant limitation. I wonder why the GC is not triggered when the
memory limit is exhausted, what would avoid the script to end
prematurely if there are uncollected cycles.
I've tried out a (maybe too
