incremental collector and finalization

[Jeff Clites]

Hi Leo:

I was reading over you incremental GC posts from about a month ago, and
read the referenced paper--quite nice work you've done in implementing
the ideas there.

I have one question: What about finalizers? I may have just missed it,
but it would seem that calling finalizers would require another sweep
over the items newly resident on the free list (the left-over items in
the from-space), which would (unfortunately) take time proportional to
the number of freed object.

BUT, a nifty thing would be to actually delay finalization until an
object is about to be re-used off of the free list. That is, treat ecru
items as only-maybe free, and as they are pulled off of the free list
for re-use, check to see if a finalizer needed to be called and if so,
call it and move on to the next item on the free list (as the first one
may now be referenced, and should be marked grey). This would allow
finalization to be treated incrementally, at the cost of it happening
"later" than it would otherwise (which I think is fine). But maybe this
is what you had in mind already. This doesn't give ordered
finalization, but that may be okay.

JEff

[Jonathan Worthington]

"Jeff Clites" <jcl...@mac.com> wrote:
> I was reading over you incremental GC posts from about a month ago, and
> read the referenced paper--quite nice work you've done in implementing
> the ideas there.
>
> I have one question: What about finalizers? I may have just missed it,
> but it would seem that calling finalizers would require another sweep
> over the items newly resident on the free list (the left-over items in
> the from-space), which would (unfortunately) take time proportional to
> the number of freed object.
>
> BUT, a nifty thing would be to actually delay finalization until an
> object is about to be re-used off of the free list. That is, treat ecru
> items as only-maybe free, and as they are pulled off of the free list
> for re-use, check to see if a finalizer needed to be called and if so,
> call it and move on to the next item on the free list (as the first one
> may now be referenced, and should be marked grey). This would allow
> finalization to be treated incrementally, at the cost of it happening
> "later" than it would otherwise (which I think is fine).

What about things that need timely destruction?

Jonathan

[Leopold Toetsch]

Jeff Clites wrote:
> Hi Leo:
>
> I was reading over you incremental GC posts from about a month ago, and
> read the referenced paper--quite nice work you've done in implementing
> the ideas there.
>
> I have one question: What about finalizers? I may have just missed it,
> but it would seem that calling finalizers would require another sweep
> over the items newly resident on the free list (the left-over items in
> the from-space), which would (unfortunately) take time proportional to
> the number of freed object.

I think that the destroy and finalize actions should get separated, the
latter would be a new vtable. The C<destroy> vtable is responsible for
freeing system resources like malloced memory. C<finalize> should do
more highlevel destruction like closing DB connections.

Objects that have finalizers would need special handling (as well as
objects that need timely destruction). We could probably allocate such
objects from a special PMC pool, so that we don't have to sweep over all
PMCs.
There is of course still the problem of ordered finalization and
destruction.

leo