[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] limit number of live finalizers

From: Jim Ursetto
Subject: Re: [Chicken-hackers] [PATCH] limit number of live finalizers
Date: Sat, 23 Jun 2012 19:04:11 -0500

Here's some background information from when this problem
first reared its head six years ago.

Summary.  Although the GC is capable of queuing only a subset of
pendable finalizers (in case the pending buffer is fixed-size
and too small) at each major GC, this may result in a space leak
in tight loops that allocate a lot of finalizable objects.
Ideally we would ensure pending buffer size > live finalizers, so
all finalizers can be invoked in one shot if needed.  To help with this,
a major GC is forced whenever a new finalizer is registered AND
the total number of active finalizers is greater than the pending
buffer size.  This MAY free up some of the live finalizers and
bring the total below the pending buffer size, satisfying our
condition.  Note that the actual fullness of the pending buffer is
not considered in this solution.

Unfortunately, though this helps for short-lived objects it
loses for long-lived ones: if live finalizers > pending buffer size,
but all those finalizable objects are in use, the major GC does
no useful work, but will still be called every for every new registered
finalizer.  This is a gigantic performance hit, of course.
That's why the pending array was made resizable, and it fixes
both cases.  So I'm crossing my fingers that there is not an
unfixable flaw in the resizing solution.


On Jun 23, 2012, at 7:53 AM, Peter Bex wrote:

> On Sat, Jun 23, 2012 at 02:47:49PM +0200, Felix wrote:
>> This patch limits the number of available finalizers (currently to
>> 4096) and removes the dynamic resizing of the "pending finalizers
>> vector", which is IMHO the cause of crashes when finalizers are
>> created excessively. Contrary to an earlier e-mail I do now think that
>> this problem needs to be fixed right now and should not be postponed
>> to a later release (and I do not see any other solution in the
>> moment). 
> I agree it must be fixed in the upcoming release.
>> User programs can override the finalizer limit using the "-:f" runtime
>> option if a large number of finalizations are expected or required in 
>> specific applications.
> I'd like a little more time to investigate the bug.  This patch can
> always be applied.  It would be a shame if we can come up with a better
> fix after this makes it into the release.
> Cheers,
> Peter
> -- 
> --
> "The process of preparing programs for a digital computer
> is especially attractive, not only because it can be economically
> and scientifically rewarding, but also because it can be an aesthetic
> experience much like composing poetry or music."
>                                                       -- Donald Knuth
> _______________________________________________
> Chicken-hackers mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]