[Vm-dev] [ENH] A better finalization support (VM & language side)

Igor Stasenko siguctua at gmail.com
Sun Mar 14 01:55:57 UTC 2010

On 14 March 2010 03:25, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Sat, Mar 13, 2010 at 3:45 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> Guys, i need your opinion on this.
>> What are you generally thinking about this idea?
>> If it ok in general, and you want it to be in VM, then i will continue
>> with my effort to fix all remarks, which
>> Levente and others pointed out.
>> But since only Levente and Andreas commented this so far, and i can't
>> decide if this feature is accepted by
>> others or not.
>> If you think this is not the way to go, please explain why you think that.
>> Sure thing i, as an author want this change to be integrated.
> I'm not sure I understand the semantics yet.  Andreas and I discussed it a little today and we thought that is that it is a way of associating a finalizer with a specific object such that the such that the object is still alive when it is finalized.  But now I reread your proposal it looks like the finalizer gets run only when its object has been collected.
> The most important thing is for the finalization system not to be post-mortem (not run a finalization action when the object is already dead).  Consider a buffered file.  The finalization action should flush the buffer as well as close the file handle.  If the finalization is post-mortem then one finalizes a copy of the file.  Hence to ensure that the copy has the same buffer state one has to update the copy every time the real file's buffer changes state, and that's bad for performance.

Its not very good example to show an advantage of pre-mortem
finalization over post-mortem.
You could implement a correct finalization scheme of the above using
post-mortem finalization, by simply keeping a buffer state in a
separate object, to which both, an object (which is going to die) and
finalizer (or executor) referencing:

weak ref -> file (buffer, handle)
strong ref -> finalizer of file (buffer , handle)

in case , when file collected, you still having a valid reference to
its buffer in finalizer, which having the very same state (since it is
the same object), and so, you could flush that buffer and then close
the handle without losing data.

> If I've misunderstood the proposal then please try and write a more comprehensible specification.  If however the proposal still does post-mortem finalization then IMO its not worth it and we should try and implement a pre-mortem scheme where the garbage collector detects when an object is about to be collected (usually implemented by the GC detecting when the object is only referenced from finalizers, and queueing the finalizers).

I think you understood it well. Its a small modification to current
post-mortem finalization, which allows us to react directly only on
those objects, which been collected.
To describe it primitively:
Suppose that you having a number of weak references, held by a single
container (WeakArray or other, not really matter).
Now at some point you want to find out, how many of objects in it is
collected after a while (you could choose to do a check immediately
after each GC, or can do it periodically - not really matters).
In current implementation it is possible to do it only by scanning a
full contents of container , in order to find which references
replaced by nil.
In scheme which i proposed, you could avoid a full scan, which is in a
linear dependency from container size, and react directly only on
those elements which collected.
This means that if your container size is X , old scheme implies to
loop through X elements to find those who collected,
while new scheme is always O(n), where n is the number of elements
which being collected.

>> cheers
> Eliot
>> --
>> Best regards,
>> Igor Stasenko AKA sig.

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list