[Mono-dev] Few notes about finalization

[Konrad M. Kruczynski]

Hi all,
it is rather known fact that adding a finalizer to the class can hurt
performance quite badly with generational garbage collectors. This is
due to the premortem finalization used by CLR. If an object is not
reachable during GC, but has a finalizer, it will survive and probably
be promoted to the next generation. Not so bad in its essence, but such
object will transitively make all referenced objects alive and these
will be promoted as well.

Consider simple benchmark contained in the attached file Test705.cs. The
intstances of classes are being born and dying, also they have reference
to the table of objects. The class A has an finalizer. On my computer
(SGEN, Mono 2.10.8) the result is:

    Took 00:00:32.4182579

If you comment out the finalizer, the result is:

    Took 00:00:04.2515352

So the difference is significant.

Most of the time (at least from my experience) developers do not need
premortem finalization. That is, they do not need to have the reference
to the instance that is being finalized. What they need is some kind of
simple callback called after this instance is GCd (the callback could
also have some kind of parameter related to such instance). As you can
see, this is also the case in the mentioned example -- the reference to
the original instance is not needed.

When I encountered internal sgen API for reference queues, I thought
that this could be used to do postmortem finalization. Unfortunately,
the API was not stable yet and therefore not public.

But there is another, very simple idea. Instead of having a finalizer in
A, one could do dummy class B (with its own finalizer) to instance of
which A would have a reference. Therefore B's finalizer would serve as a
callback function of A.

The attached example Test706.cs is based on this idea. And the result
is:

    Took 00:00:04.6424758

So it is in the same order of magnitude.

Yup, this is very simple idea, nonetheless works well and did not come
to me as a solution immediately, so maybe this will be useful to
someone. Or I am wrong somewhere ;)

--
Best regards,
 Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test706.cs
Type: text/x-csharp
Size: 879 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121205/729309a2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test705.cs
Type: text/x-csharp
Size: 787 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121205/729309a2/attachment-0001.bin>