[Gd-hackers] Suggested patch for Open Dylan's C runtime

[Bruce Hoult]

On 7/31/07, Thomas Christian Chust <chust at web.de> wrote:
> But anyway, I think this is about the only way to force the Boehm
> garbage collector into an approximately correct behaviour for
> finalization queues: If I don't put the object pointer into a queue
> allocated with the garbage collector, it gets discarded immediately
> after the finalizer has run.

No, the existence of the finalizer has already saved it from that GC.
The space will only be reused if the object is not pointed to by
anything on the *next* GC.


> The only acceptable alternative I can think of that avoids allocation in
> the C-level finalizer would be to preallocate an array list to use as
> the finalization queue. But that would pose an artificial size limit on
> the finalization queue.

You could allocate the list link for the object at the point that you
register the finalizer for it (possibly as part of the object itself
if you have control over that by, for example, allocating an extra 4
bytes and lying to the rest of Dylan about where the object starts).

In fact if you want to guaranteed that finalizers will be run before
program exit then you have to do that anyway.  Then you'll have the
actual finalizer remove the object from the program exit cleanup list.

You can also use the facility in Boehm for asynchronous finalization
using the  GC_invoke_finalizers() function and either setting your own
function into the GC_finalizer_notifier variable or else polling
GC_should_invoke_finalizers().  So you can for example set
GC_finalizer_notifier to point to a function that clears a semaphore
that releases a thread that calls GC_invoke_finalizers().  No need to
keep track of anything else yourself.  The GC won't delete the objects
until after GC_invoke_finalizers() has been called, even if there is
another GC in the meantime.

(I will add all this stuff to d2c if/when it supports threads ...)