[Mono-dev] Reference queue

[Konrad M. Kruczyński]

Hi all,
I think I was misunderstood. This is not beginner's question on how to
write classes with Disposable pattern (you mentioned) -- believe me, I
know that very well. Problem is rather as follows. Let's say we have an
object whose life is short - it is collected on first GC scan after
creation. But then if it has a finalizer it is not collected. Instead,
it is marked for finalization. After some time its finalizer is called.
And it is finally collected after next GC scan - so much more later than
in the first case. Things will get worse if it will be promoted to next
generation in the meantime. In other words such kind of object with
finalizer will stay in memory longer than it should and that is the
source of performance problems I mentioned. It can also hold reference
to another (fully managed) objects, that one to another and so on.

This is well known problem with objects implementing finalizers and one
of the reasons (among unpredictability) for recommending explicit (via
Dispose) release. But how can one do that if object is shared (the thing
you would, for instance in C++, do with reference counting)? Finalizers
are best as back-ups for such release, not the main mean, as you have
written.

I think that callback after death mechanism is the solution here. About
the I/O operation invoked - I would not put it in the callback directly,
rather enqueue it in thread pool.

Oh, I've just found an article which talks about what I exactly meant:
http://www.bluebytesoftware.com/blog/2011/11/12/ABriefNoteOnObjectMortality.aspx
Apparently this is possible in Java. It could be therefore useful also
for IKVM, as it has to be provided by it. I do not know how it is
implemented in it currently - probably using small objects with
finalizers on which they make proper notifications.

I hope it is clearer now.

--
Regards,
 Konrad